cosign-discuss — All questions and comments regarding Cosign deployment and development.

[Cosign-discuss] R: Cosign cookie question

[Siri L. A. <let...@it...>]

Thank you very much Brian, this is a great solution.

I have tested it in our project and it works perfectly.

I apologize if I disturbed, in fact in the file cosign.conf.5 this possibility was described, but the project is old and the current configuration did not foresee the use of regular expressions.

In the next release I think I will use them as you indicated.

Thank you

Letizia Siri

Da: Brian Rahn <bd...@um...>
Inviato: mercoledì 30 giugno 2021 16:42
A: Siri Letizia Angela <let...@it...>
Cc: cos...@li...
Oggetto: Re: Cosign cookie question

We solve that in our own installation with a default rule that uses regular expressions:
service cosign-(.*)                  https://$1.umich.edu/cosign/valid<http://1.umich.edu/cosign/valid>  0  (.*)\.umich.edu<http://umich.edu>        cosign-$1

The server running www.umich.edu<http://www.umich.edu> has a service name of cosign-www. Users are redirected to https://www.umich.edu/cosign/valid. The servers use their www.umich.edu<http://www.umich.edu> certificate to connect back to cosignd. That means new services can join the Cosign SSO without any changes on the Cosign side.

Brian Rahn

On Wed, Jun 30, 2021 at 4:53 AM Siri Letizia Angela <let...@it...<mailto:let...@it...>> wrote:
Hi Brian,

Maybe we used improperly cosign, we wanted to avoid a service architecture being exposed in the centralized configuration of the cosignd daemon, at the same time we wanted to protect all components of the service from unauthenticated access and share realm.

This is a distributed system where the centralized cosignd daemon is delivered with its own rpm while the services are released separately, so we wanted to avoid a contextual update of the two.

As said I have separated the service into two services, so this is the right direction, isn't it?

Thank you very much for your attention and for quick replying.

Letizia Siri

Da: Brian Rahn <bd...@um...<mailto:bd...@um...>>
Inviato: martedì 29 giugno 2021 19:20
A: Siri Letizia Angela <let...@it...<mailto:let...@it...>>
Cc: cos...@li...<mailto:cos...@li...>
Oggetto: Re: Cosign cookie question

I don't believe there was a direct effort to make the filters incompatible. They were developed separately to meet the same standard.

That said, the filters will keep separate cookie caches each requiring their own rechecks through separate connection pools. They are separate services, even if you name them the same. I'm not sure what you gain by mixing them.

Brian Rahn

Re: [Cosign-discuss] Cosign cookie question

[Brian R. <bd...@um...>]

We solve that in our own installation with a default rule that uses regular
expressions:
service cosign-(.*)                  https://$1.umich.edu/cosign/valid  0
 (.*)\.umich.edu        cosign-$1

The server running www.umich.edu has a service name of cosign-www. Users
are redirected to https://www.umich.edu/cosign/valid. The servers use their
www.umich.edu certificate to connect back to cosignd. That means new
services can join the Cosign SSO without any changes on the Cosign side.

Brian Rahn

On Wed, Jun 30, 2021 at 4:53 AM Siri Letizia Angela <
let...@it...> wrote:

> Hi Brian,
>
>
>
> Maybe we used improperly cosign, we wanted to avoid a service architecture
> being exposed in the centralized configuration of the cosignd daemon, at
> the same time we wanted to protect all components of the service from
> unauthenticated access and share realm.
>
>
>
> This is a distributed system where the centralized cosignd daemon is
> delivered with its own rpm while the services are released separately, so
> we wanted to avoid a contextual update of the two.
>
>
>
> As said I have separated the service into two services, so this is the
> right direction, isn't it?
>
>
>
> Thank you very much for your attention and for quick replying.
>
>
>
> Letizia Siri
>
>
>
> *Da:* Brian Rahn <bd...@um...>
> *Inviato:* martedì 29 giugno 2021 19:20
> *A:* Siri Letizia Angela <let...@it...>
> *Cc:* cos...@li...
> *Oggetto:* Re: Cosign cookie question
>
>
>
> I don't believe there was a direct effort to make the filters
> incompatible. They were developed separately to meet the same standard.
>
>
>
> That said, the filters will keep separate cookie caches each requiring
> their own rechecks through separate connection pools. They are separate
> services, even if you name them the same. I'm not sure what you gain by
> mixing them.
>
>
>
> Brian Rahn
>
>

[Cosign-discuss] R: Cosign cookie question

[Siri L. A. <let...@it...>]

Hi Brian,

Maybe we used improperly cosign, we wanted to avoid a service architecture being exposed in the centralized configuration of the cosignd daemon, at the same time we wanted to protect all components of the service from unauthenticated access and share realm.

This is a distributed system where the centralized cosignd daemon is delivered with its own rpm while the services are released separately, so we wanted to avoid a contextual update of the two.

As said I have separated the service into two services, so this is the right direction, isn't it?

Thank you very much for your attention and for quick replying.

Letizia Siri

Da: Brian Rahn <bd...@um...>
Inviato: martedì 29 giugno 2021 19:20
A: Siri Letizia Angela <let...@it...>
Cc: cos...@li...
Oggetto: Re: Cosign cookie question

I don't believe there was a direct effort to make the filters incompatible. They were developed separately to meet the same standard.

That said, the filters will keep separate cookie caches each requiring their own rechecks through separate connection pools. They are separate services, even if you name them the same. I'm not sure what you gain by mixing them.

Brian Rahn

On Tue, Jun 29, 2021 at 12:42 PM Siri Letizia Angela <let...@it...<mailto:let...@it...>> wrote:
Hi,
working on project that use cosign, I’ve noticed that cookie time is in milliseconds if created by java filter, while is in seconds if created by mod_cosign.so.

Here is an example generated by java filter:

cosign-serv1=xWHucaNmqP9FLF-GJDB7Lft9QYTXRRIJGfo8ssL9JNuGINCB7MUANIRH3GkT+kOHNelyl1o4PAFmcEz8EeA+FwiqjA1OXh-V4Re1LOewNEUfrE-1G5DhOSthJRfk/1624979055037

and this is from mod_cosign.so:

cosign-serv2=BW5qU8OSJ7e3ldPxzVbccT3BJt8bR4hy43CoaNah8ALS+IEtqCDzLYzLWR7Qb9Bier5O-Q-MTQiKRleiCcxBpRTS7wwEjnJOrwnwuc4+OdwTEg-OkYNmAaEXWVMZ/1624979069

If mod_cosign.so manages a cookie created by the java application it has unpredictable behavior due to this line:

cookietime = atoi( misc );

where cookietime is an int.

At the moment to work around  this problem I have defined two distinct services.

I’ve also tested this change to cosign_auth function in filters/apache2/mod_cosign.c:

  /* if it's a stale cookie, give out a new one */
    gettimeofday( &now, NULL );
    (void)strtok( my_cookie, "/" );
    if (( misc = strtok( NULL, "/" )) != NULL ) {
        dim = strlen(misc);
        if (dim > 10) misc[10] = '\0';
        cookietime = atoi( misc );
    }
    if (( cookietime > 0 ) && ( now.tv_sec - cookietime ) > cfg->expiretime ) {
        goto redirect;
    }

With this I can share cookie created by java application in virtualhost protected by mod_cosign.so.

I haven't tested if the java filter fails by receiving a cookie created by mod_cosign.so.

I would like to know if it is a choice not to be able to have services implemented with different technologies and which share the cookie.
Thanks in advance

[cid:image001.png@01D76D9A.1D278780]
[cid:image002.jpg@01D76D9A.1D278780]
Letizia Angela Siri
Software Engineer
Open Network & Platform
Italtel S.p.A.
Via Reiss Romoli
20019 Settimo Milanese -  MI - Italy
email: let...@it...<mailto:let...@it...>
P: +39 0243881 - +39 0243887195
www.italtel.com<http://www.italtel.com/>
[cid:image003.jpg@01D76D9A.1D278780]<http://www.linkedin.com/company/italtel?trk=top_nav_home>[cid:image004.png@01D76D9A.1D278780]<http://www.twitter.com/intent/follow?original_referer=http://twitter.com/goodies2Fbuttons&screen_name=italtel&source=followbutton&variant=2.0> [cid:image005.jpg@01D76D9A.1D278780] <https://www.instagram.com/italtel_hq/>  [cid:image006.png@01D76D9A.1D278780] <http://www.youtube.com/user/ItaltelChannel>

[Cosign-discuss] Cosign cookie question

[Siri L. A. <let...@it...>]

Hi,
working on project that use cosign, I've noticed that cookie time is in milliseconds if created by java filter, while is in seconds if created by mod_cosign.so.

Here is an example generated by java filter:

cosign-serv1=xWHucaNmqP9FLF-GJDB7Lft9QYTXRRIJGfo8ssL9JNuGINCB7MUANIRH3GkT+kOHNelyl1o4PAFmcEz8EeA+FwiqjA1OXh-V4Re1LOewNEUfrE-1G5DhOSthJRfk/1624979055037

and this is from mod_cosign.so:

cosign-serv2=BW5qU8OSJ7e3ldPxzVbccT3BJt8bR4hy43CoaNah8ALS+IEtqCDzLYzLWR7Qb9Bier5O-Q-MTQiKRleiCcxBpRTS7wwEjnJOrwnwuc4+OdwTEg-OkYNmAaEXWVMZ/1624979069

If mod_cosign.so manages a cookie created by the java application it has unpredictable behavior due to this line:

cookietime = atoi( misc );

where cookietime is an int.

At the moment to work around  this problem I have defined two distinct services.

I've also tested this change to cosign_auth function in filters/apache2/mod_cosign.c:

  /* if it's a stale cookie, give out a new one */
    gettimeofday( &now, NULL );
    (void)strtok( my_cookie, "/" );
    if (( misc = strtok( NULL, "/" )) != NULL ) {
        dim = strlen(misc);
        if (dim > 10) misc[10] = '\0';
        cookietime = atoi( misc );
    }
    if (( cookietime > 0 ) && ( now.tv_sec - cookietime ) > cfg->expiretime ) {
        goto redirect;
    }

With this I can share cookie created by java application in virtualhost protected by mod_cosign.so.

I haven't tested if the java filter fails by receiving a cookie created by mod_cosign.so.

I would like to know if it is a choice not to be able to have services implemented with different technologies and which share the cookie.
Thanks in advance

[cid:image002.png@01D76D16.7ADAD9B0]
[cid:image003.jpg@01D76D10.FB2CCAC0]
Letizia Angela Siri
Software Engineer
Open Network & Platform
Italtel S.p.A.
Via Reiss Romoli
20019 Settimo Milanese -  MI - Italy
email: let...@it...<mailto:let...@it...>
P: +39 0243881 - +39 0243887195
www.italtel.com<http://www.italtel.com/>
[cid:image004.jpg@01D76D10.FB2CCAC0]<http://www.linkedin.com/company/italtel?trk=top_nav_home> [cid:image005.png@01D76D10.FB2CCAC0] <http://www.twitter.com/intent/follow?original_referer=http://twitter.com/goodies2Fbuttons&screen_name=italtel&source=followbutton&variant=2.0>  [cid:image006.jpg@01D76D10.FB2CCAC0] <https://www.instagram.com/italtel_hq/>  [cid:image007.png@01D76D10.FB2CCAC0] <http://www.youtube.com/user/ItaltelChannel>

Re: [Cosign-discuss] Cosign cookie question

[Brian R. <bd...@um...>]

I don't believe there was a direct effort to make the filters incompatible.
They were developed separately to meet the same standard.

That said, the filters will keep separate cookie caches each requiring
their own rechecks through separate connection pools. They are separate
services, even if you name them the same. I'm not sure what you gain by
mixing them.

Brian Rahn

On Tue, Jun 29, 2021 at 12:42 PM Siri Letizia Angela <
let...@it...> wrote:

> Hi,
>
> working on project that use *cosign*, I’ve noticed that cookie time is in
> milliseconds if created by java filter, while is in seconds if created by
> mod_cosign.so.
>
>
>
> Here is an example generated by java filter:
>
>
>
>
> cosign-serv1=xWHucaNmqP9FLF-GJDB7Lft9QYTXRRIJGfo8ssL9JNuGINCB7MUANIRH3GkT+kOHNelyl1o4PAFmcEz8EeA+FwiqjA1OXh-V4Re1LOewNEUfrE-1G5DhOSthJRfk/
> 1624979055037
>
>
>
> and this is from mod_cosign.so:
>
>
>
>
> cosign-serv2=BW5qU8OSJ7e3ldPxzVbccT3BJt8bR4hy43CoaNah8ALS+IEtqCDzLYzLWR7Qb9Bier5O-Q-MTQiKRleiCcxBpRTS7wwEjnJOrwnwuc4+OdwTEg-OkYNmAaEXWVMZ/
> 1624979069
>
>
>
> If *mod_cosign.so* manages a cookie created by the java application it
> has unpredictable behavior due to this line:
>
>
>
> cookietime = atoi( misc );
>
>
>
> where cookietime is an int.
>
>
>
> At the moment to work around  this problem I have defined two distinct
> services.
>
>
>
> I’ve also tested this change to cosign_auth function in
> filters/apache2/mod_cosign.c:
>
>
>
>   /* if it's a stale cookie, give out a new one */
>
>     gettimeofday( &now, NULL );
>
>     (void)strtok( my_cookie, "/" );
>
>     if (( misc = strtok( NULL, "/" )) != NULL ) {
>
>         dim = strlen(misc);
>
>         if (dim > 10) misc[10] = '\0';
>
>         cookietime = atoi( misc );
>
>     }
>
>     if (( cookietime > 0 ) && ( now.tv_sec - cookietime ) >
> cfg->expiretime ) {
>
>         goto redirect;
>
>     }
>
>
>
> With this I can share cookie created by java application in virtualhost
> protected by mod_cosign.so.
>
>
>
> I haven't tested if the java filter fails by receiving a cookie created by
> mod_cosign.so.
>
>
>
> I would like to know if it is a choice not to be able to have services
> implemented with different technologies and which share the cookie.
>
> Thanks in advance
>
>
>
> *Letizia Angela Siri*
>
> *Software Engineer*
>
> *Open Network & Platform*
>
> *Italtel S.p.A.*
>
> Via Reiss Romoli
>
> 20019 Settimo Milanese -  MI - Italy
>
> email: let...@it...
>
> P: +39 0243881 - +39 0243887195
>
> *www.italtel.com <http://www.italtel.com/>*
>
> <http://www.linkedin.com/company/italtel?trk=top_nav_home>
> <http://www.twitter.com/intent/follow?original_referer=http://twitter.com/goodies2Fbuttons&screen_name=italtel&source=followbutton&variant=2.0>
>   <https://www.instagram.com/italtel_hq/>
> <http://www.youtube.com/user/ItaltelChannel>
>
>
>

[Cosign-discuss] Question about IIS authentication

[Balzer, E. M. <em...@ps...>]

We're using cosign 3.1.1 and installed the filter on an IIS server (version 10). Cosign places authenticated user information in Request.ServerVariables["REMOTE_USER"] and everything works fine. The problem I'm having is in implementing some anti-CSRF code (out of the box asp.net mvc AntiForgery libraries). When my post submits the token for validation, the AntiForgery code rejects it with this error:

The provided anti-forgery token was meant for user "xxx", but the current user is "".

I believe I need to somehow get the username into the token but I'm not sure how to do that. The IIS server is configured to use Anonymous Authentication, and that seems to be a requirement since any other choice (ASP.NET impersonation, Forms or Windows Authentication) all require a separate login against a non-existent provider (since cosign IS the provider).

Does anyone have any suggestion for how to work around this problem?

Thanks in advance.


Edward (Ned) Balzer
Programmer/Analyst
814-863-5950 | em...@ps...<mailto:em...@ps...>

INFORMATION TECHNOLOGY LIBERAL ARTS
Penn State University | Greenleaf Park One
2013 Sandy Drive, Suite 201
State College, PA 16803
814-865-3412 | lah...@ps...<mailto:lah...@ps...> | http://itla.la.psu.edu

Re: [Cosign-discuss] cosign and apache 2.4, actual mod_cosign bug

[Liam H. <li...@um...>]

Hi Chris -

The developer who is owns the main cosign repository (
https://github.com/umich-iam/cosign) has been totally unresponsive for
several years.
Our institution is moving away from cosign, but we do have a repo that sees
some maintenance - https://github.com/umich-iam/cosign
You could switch your remotes and issue a pull requests against us.

Liam

On Mon, Aug 20, 2018 at 2:31 PM, Chris Hecker <ch...@d6...> wrote:

>
> I'm trying to update my server that runs CoSign from httpd 2.2.x to 2.4.x,
> and I've got things building (there are several pull requests on
> https://github.com/cosignweblogin/cosign to fix the minor build errors),
> but I think I've found a more serious code bug:
>
> Due to https://nvd.nist.gov/vuln/detail/CVE-2015-3185, they have
> deprecated ap_some_auth_required and have silently made it incompatible
> with 2.2 semantics, and they want people to switch to ap_some_auth*n*_required,
> which has some reentry issues.  They're claiming ap_some_auth_required now
> is a security hole, which appears to be the case for me, meaning it
> circumvents the cosign redirect when there's no cookie.
>
> I'm working on a real patch, but I'm wondering if anybody else has run
> into this.  Sadly, getting it built on 2.4 is not the only problem.  I know
> CoSign is not really active anymore but I'd assume some folks have updated
> like this and run into the problem?
>
> Is there a plan to at least take patches on the github repo?
>
> Chris
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>

Re: [Cosign-discuss] cosign and apache 2.4, actual mod_cosign bug

[Qais P. <me...@qa...>]

Apologies. I have deferred to writing my own filter for Cosign (not using
Apache), that's why I haven't encountered this.

Best of luck,

Qais

On Tue, 21 Aug 2018 at 07:22 Chris Hecker <ch...@d6...> wrote:

>
> I have it fixed locally.  I'm testing it now.
>
> It appears to rear its head if you switch from the old deprecated Order,
> Allow, Deny syntax to the newer 2.4 Required syntax.  Are you on the old
> syntax still?
>
>
> Chris
>
>
>
>
>
> On 2018-08-20 23:19, Qais Patankar wrote:
>
> I haven't run into this issue but I'm looking forward to hearing if
> patches on GitHub will be considered.
>
> The repository is fairly pointless if not.
>
> Qais
>
> On Mon, 20 Aug 2018 at 21:24 Chris Hecker <ch...@d6...> wrote:
>
>>
>> I'm trying to update my server that runs CoSign from httpd 2.2.x to
>> 2.4.x, and I've got things building (there are several pull requests on
>> https://github.com/cosignweblogin/cosign to fix the minor build errors),
>> but I think I've found a more serious code bug:
>>
>> Due to https://nvd.nist.gov/vuln/detail/CVE-2015-3185, they have
>> deprecated ap_some_auth_required and have silently made it incompatible
>> with 2.2 semantics, and they want people to switch to ap_some_auth*n*_required,
>> which has some reentry issues.  They're claiming ap_some_auth_required now
>> is a security hole, which appears to be the case for me, meaning it
>> circumvents the cosign redirect when there's no cookie.
>>
>> I'm working on a real patch, but I'm wondering if anybody else has run
>> into this.  Sadly, getting it built on 2.4 is not the only problem.  I know
>> CoSign is not really active anymore but I'd assume some folks have updated
>> like this and run into the problem?
>>
>> Is there a plan to at least take patches on the github repo?
>>
>> Chris
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Cosign-discuss mailing list
>> Cos...@li...
>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>>
>
>

Re: [Cosign-discuss] cosign and apache 2.4, actual mod_cosign bug

[Chris H. <ch...@d6...>]

I have it fixed locally.  I'm testing it now.

It appears to rear its head if you switch from the old deprecated Order,
Allow, Deny syntax to the newer 2.4 Required syntax.  Are you on the old
syntax still?

Chris




On 2018-08-20 23:19, Qais Patankar wrote:
> I haven't run into this issue but I'm looking forward to hearing if
> patches on GitHub will be considered.
>
> The repository is fairly pointless if not.
>
> Qais
>
> On Mon, 20 Aug 2018 at 21:24 Chris Hecker <ch...@d6...
> <mailto:ch...@d6...>> wrote:
>
>
>     I'm trying to update my server that runs CoSign from httpd 2.2.x
>     to 2.4.x, and I've got things building (there are several pull
>     requests on https://github.com/cosignweblogin/cosign to fix the
>     minor build errors), but I think I've found a more serious code bug:
>
>     Due to https://nvd.nist.gov/vuln/detail/CVE-2015-3185, they have
>     deprecated ap_some_auth_required and have silently made it
>     incompatible with 2.2 semantics, and they want people to switch to
>     ap_some_auth*n*_required, which has some reentry issues.  They're
>     claiming ap_some_auth_required now is a security hole, which
>     appears to be the case for me, meaning it circumvents the cosign
>     redirect when there's no cookie.
>
>     I'm working on a real patch, but I'm wondering if anybody else has
>     run into this.  Sadly, getting it built on 2.4 is not the only
>     problem.  I know CoSign is not really active anymore but I'd
>     assume some folks have updated like this and run into the problem?
>
>     Is there a plan to at least take patches on the github repo?
>
>     Chris
>
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org!
>     http://sdm.link/slashdot_______________________________________________
>     Cosign-discuss mailing list
>     Cos...@li...
>     <mailto:Cos...@li...>
>     https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>

[Cosign-discuss] cosign and apache 2.4, actual mod_cosign bug

[Chris H. <ch...@d6...>]

I'm trying to update my server that runs CoSign from httpd 2.2.x to
2.4.x, and I've got things building (there are several pull requests on
https://github.com/cosignweblogin/cosign to fix the minor build errors),
but I think I've found a more serious code bug:

Due to https://nvd.nist.gov/vuln/detail/CVE-2015-3185, they have
deprecated ap_some_auth_required and have silently made it incompatible
with 2.2 semantics, and they want people to switch to
ap_some_auth*n*_required, which has some reentry issues.  They're
claiming ap_some_auth_required now is a security hole, which appears to
be the case for me, meaning it circumvents the cosign redirect when
there's no cookie.

I'm working on a real patch, but I'm wondering if anybody else has run
into this.  Sadly, getting it built on 2.4 is not the only problem.  I
know CoSign is not really active anymore but I'd assume some folks have
updated like this and run into the problem?

Is there a plan to at least take patches on the github repo?

Chris

Re: [Cosign-discuss] cosign login with krb5 key (or tgt) possible?

[Liam H. <li...@um...>]

> Actually, you can authenticate to cosign using a Kerberos ticket via
SPNEGO, if you have SPNEGO
> configured on the central weblogin server and enabled as a factor.  There
is currently no UI to control
> this and it breaks central logout.  I set this up on a test weblogin
server many years ago, and it worked
> but was very, very rough.

The SPNEGO functionality is provided via mod_auth_kerb.  If you protect the
Cosign CGI with an alternate authentication mechanism (that provides
REMOTE_USER), Cosign will use that for authentication rather the presenting
the login UI.

Liam

On Mon, Nov 27, 2017 at 11:19 AM, Toby Blake <to...@in...> wrote:

> We do indeed still run this.  It wa discussed on this list at the time...
> starting, I think, here:
>
> https://sourceforge.net/p/cosign/mailman/message/6217667/
>
> Cheers
> Toby
>
> > On 27 Nov 2017, at 16:18, Graeme Wood <Gra...@ed...> wrote:
> >
> > Our School of Informatics had this implemented on their weblogin
> service, though I am not sure if they still do. I could ask them, if people
> are interested. It is something I had been toying with implementing on the
> main University of Edinburgh login service.
> >
> > Regards,
> > Graeme Wood
> >
> >> On 27 Nov 2017, at 16:13, Mark Montague <mar...@um...> wrote:
> >>
> >> Actually, you can authenticate to cosign using a Kerberos ticket via
> SPNEGO, if you have SPNEGO configured on the central weblogin server and
> enabled as a factor.  There is currently no UI to control this and it
> breaks central logout.  I set this up on a test weblogin server many years
> ago, and it worked but was very, very rough.
> >>
> >> X.509 is in much the same situation: you can authenticate to cosign
> using a client-side X.509 certificate, but there is currently no UI to
> manage this in cosign and it breaks central logout.
> >>
> >> The central logout breaking is due to the fact that after logout, the
> client will re-present the credentials to the central weblogin server on
> the next access that requires authentication, and the authentication will
> transparently succeed with no interaction from a user (assuming single
> factor), automatically logging the user in again for as long as the
> Kerberos ticket or X.509 certificate is valid.
> >>
> >> I am not aware of any institution that is using either SPNEGO or X.509
> with cosign.  Either one would require explicit configuration, possible UI
> enhancements, and I don't think that documentation exists for either one.
> >>
> >> --
> >>  Mark Montague
> >>
> >> mar...@um...
> >>
> >>
> >> On 2017-11-27 10:29, Brian Rahn wrote:
> >>> Cosign is firmly tied to using a login & password against a Kerberos
> realm. You would not be able to use a keytab or existing Kerberos ticket to
> authenticate. The cookies are just random strings used to reference data
> stored on the Cosign servers. They do not contain data, nor are they
> derived from data.
> >>>
> >>> On Sat, Nov 25, 2017 at 7:20 PM, Chris Hecker <ch...@d6...> wrote:
> >>>
> >>> I'm hoping the answer is 'no' for my current application, but is there
> a way for a user with a valid krb5 account on the kdc and a keytab file (or
> TGT) for that account to log into cosign without knowing the password used
> to make the key? In other words, there's no way to skip the plaintext
> password entry and pass a key or a TGT directly to cosign, right?
> >>>
> >>> Or, would it be possible to set the cookies correctly manually if the
> user has the key and/or a TGT for the key? It doesn't seem like it from
> looking at the code because then the corresponding cookie file wouldn't
> exist in the /var/cosign/daemon directory, but I wanted to make sure.
> >>>
> >>> Thanks,
> >>> Chris
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------
> ------------------
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>> _______________________________________________
> >>> Cosign-discuss mailing list
> >>> Cos...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------
> ------------------
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org!
> >>> http://sdm.link/slashdot
> >>>
> >>>
> >>> _______________________________________________
> >>> Cosign-discuss mailing list
> >>>
> >>> Cos...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> >>
> >>
> >> ------------------------------------------------------------
> ------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> >> Cosign-discuss mailing list
> >> Cos...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> >
> > --
> >
> > Graeme Wood, Enterprise Services, IT Infrastructure Division,
> > Information Services, The University of Edinburgh
> > Email: Gra...@ed... Phone: +44 131 650 5003 Fax: +44 131 650
> 6552
> >
> > The University of Edinburgh is a charitable body, registered in
> > Scotland, with registration number SC005336.
> >
> >
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Cosign-discuss mailing list
> > Cos...@li...
> > https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> >
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>

Re: [Cosign-discuss] cosign login with krb5 key (or tgt) possible?

[Toby B. <to...@in...>]

We do indeed still run this.  It wa discussed on this list at the time...
starting, I think, here:

https://sourceforge.net/p/cosign/mailman/message/6217667/

Cheers
Toby

> On 27 Nov 2017, at 16:18, Graeme Wood <Gra...@ed...> wrote:
> 
> Our School of Informatics had this implemented on their weblogin service, though I am not sure if they still do. I could ask them, if people are interested. It is something I had been toying with implementing on the main University of Edinburgh login service.
> 
> Regards,
> Graeme Wood
> 
>> On 27 Nov 2017, at 16:13, Mark Montague <mar...@um...> wrote:
>> 
>> Actually, you can authenticate to cosign using a Kerberos ticket via SPNEGO, if you have SPNEGO configured on the central weblogin server and enabled as a factor.  There is currently no UI to control this and it breaks central logout.  I set this up on a test weblogin server many years ago, and it worked but was very, very rough.
>> 
>> X.509 is in much the same situation: you can authenticate to cosign using a client-side X.509 certificate, but there is currently no UI to manage this in cosign and it breaks central logout.
>> 
>> The central logout breaking is due to the fact that after logout, the client will re-present the credentials to the central weblogin server on the next access that requires authentication, and the authentication will transparently succeed with no interaction from a user (assuming single factor), automatically logging the user in again for as long as the Kerberos ticket or X.509 certificate is valid.
>> 
>> I am not aware of any institution that is using either SPNEGO or X.509 with cosign.  Either one would require explicit configuration, possible UI enhancements, and I don't think that documentation exists for either one.
>> 
>> -- 
>>  Mark Montague
>> 
>> mar...@um...
>> 
>> 
>> On 2017-11-27 10:29, Brian Rahn wrote:
>>> Cosign is firmly tied to using a login & password against a Kerberos realm. You would not be able to use a keytab or existing Kerberos ticket to authenticate. The cookies are just random strings used to reference data stored on the Cosign servers. They do not contain data, nor are they derived from data.
>>> 
>>> On Sat, Nov 25, 2017 at 7:20 PM, Chris Hecker <ch...@d6...> wrote:
>>> 
>>> I'm hoping the answer is 'no' for my current application, but is there a way for a user with a valid krb5 account on the kdc and a keytab file (or TGT) for that account to log into cosign without knowing the password used to make the key? In other words, there's no way to skip the plaintext password entry and pass a key or a TGT directly to cosign, right?
>>> 
>>> Or, would it be possible to set the cookies correctly manually if the user has the key and/or a TGT for the key? It doesn't seem like it from looking at the code because then the corresponding cookie file wouldn't exist in the /var/cosign/daemon directory, but I wanted to make sure.
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Cosign-discuss mailing list
>>> Cos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! 
>>> http://sdm.link/slashdot
>>> 
>>> 
>>> _______________________________________________
>>> Cosign-discuss mailing list
>>> 
>>> Cos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> Cosign-discuss mailing list
>> Cos...@li...
>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> 
> -- 
> 
> Graeme Wood, Enterprise Services, IT Infrastructure Division,
> Information Services, The University of Edinburgh
> Email: Gra...@ed... Phone: +44 131 650 5003 Fax: +44 131 650 6552
> 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> 


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [Cosign-discuss] cosign login with krb5 key (or tgt) possible?

[Graeme W. <Gra...@ed...>]

Our School of Informatics had this implemented on their weblogin service, though I am not sure if they still do. I could ask them, if people are interested. It is something I had been toying with implementing on the main University of Edinburgh login service.

Regards,
Graeme Wood

> On 27 Nov 2017, at 16:13, Mark Montague <mar...@um...> wrote:
> 
> Actually, you can authenticate to cosign using a Kerberos ticket via SPNEGO, if you have SPNEGO configured on the central weblogin server and enabled as a factor.  There is currently no UI to control this and it breaks central logout.  I set this up on a test weblogin server many years ago, and it worked but was very, very rough.
> 
> X.509 is in much the same situation: you can authenticate to cosign using a client-side X.509 certificate, but there is currently no UI to manage this in cosign and it breaks central logout.
> 
> The central logout breaking is due to the fact that after logout, the client will re-present the credentials to the central weblogin server on the next access that requires authentication, and the authentication will transparently succeed with no interaction from a user (assuming single factor), automatically logging the user in again for as long as the Kerberos ticket or X.509 certificate is valid.
> 
> I am not aware of any institution that is using either SPNEGO or X.509 with cosign.  Either one would require explicit configuration, possible UI enhancements, and I don't think that documentation exists for either one.
> 
> -- 
>   Mark Montague
>   
> mar...@um...
> 
> 
> On 2017-11-27 10:29, Brian Rahn wrote:
>> Cosign is firmly tied to using a login & password against a Kerberos realm. You would not be able to use a keytab or existing Kerberos ticket to authenticate. The cookies are just random strings used to reference data stored on the Cosign servers. They do not contain data, nor are they derived from data.
>> 
>> On Sat, Nov 25, 2017 at 7:20 PM, Chris Hecker <ch...@d6...> wrote:
>> 
>> I'm hoping the answer is 'no' for my current application, but is there a way for a user with a valid krb5 account on the kdc and a keytab file (or TGT) for that account to log into cosign without knowing the password used to make the key? In other words, there's no way to skip the plaintext password entry and pass a key or a TGT directly to cosign, right?
>> 
>> Or, would it be possible to set the cookies correctly manually if the user has the key and/or a TGT for the key? It doesn't seem like it from looking at the code because then the corresponding cookie file wouldn't exist in the /var/cosign/daemon directory, but I wanted to make sure.
>> 
>> Thanks,
>> Chris
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Cosign-discuss mailing list
>> Cos...@li...
>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! 
>> http://sdm.link/slashdot
>> 
>> 
>> _______________________________________________
>> Cosign-discuss mailing list
>> 
>> Cos...@li...
>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> Cosign-discuss mailing list
> Cos...@li...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss

-- 

Graeme Wood, Enterprise Services, IT Infrastructure Division,
Information Services, The University of Edinburgh
Email: Gra...@ed... Phone: +44 131 650 5003 Fax: +44 131 650 6552

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [Cosign-discuss] cosign login with krb5 key (or tgt) possible?

[Mark M. <mar...@um...>]

Actually, you can authenticate to cosign using a Kerberos ticket via 
SPNEGO, if you have SPNEGO configured on the central weblogin server and 
enabled as a factor.  There is currently no UI to control this and it 
breaks central logout.  I set this up on a test weblogin server many 
years ago, and it worked but was very, very rough.

X.509 is in much the same situation: you can authenticate to cosign 
using a client-side X.509 certificate, but there is currently no UI to 
manage this in cosign and it breaks central logout.

The central logout breaking is due to the fact that after logout, the 
client will re-present the credentials to the central weblogin server on 
the next access that requires authentication, and the authentication 
will transparently succeed with no interaction from a user (assuming 
single factor), automatically logging the user in again for as long as 
the Kerberos ticket or X.509 certificate is valid.

I am not aware of any institution that is using either SPNEGO or X.509 
with cosign.  Either one would require explicit configuration, possible 
UI enhancements, and I don't think that documentation exists for either one.

-- 
   Mark Montague
   mar...@um...



On 2017-11-27 10:29, Brian Rahn wrote:
> Cosign is firmly tied to using a login & password against a Kerberos 
> realm. You would not be able to use a keytab or existing Kerberos 
> ticket to authenticate. The cookies are just random strings used to 
> reference data stored on the Cosign servers. They do not contain data, 
> nor are they derived from data.
>
> On Sat, Nov 25, 2017 at 7:20 PM, Chris Hecker <ch...@d6... 
> <mailto:ch...@d6...>> wrote:
>
>
>     I'm hoping the answer is 'no' for my current application, but is
>     there a way for a user with a valid krb5 account on the kdc and a
>     keytab file (or TGT) for that account to log into cosign without
>     knowing the password used to make the key? In other words, there's
>     no way to skip the plaintext password entry and pass a key or a
>     TGT directly to cosign, right?
>
>     Or, would it be possible to set the cookies correctly manually if
>     the user has the key and/or a TGT for the key? It doesn't seem
>     like it from looking at the code because then the corresponding
>     cookie file wouldn't exist in the /var/cosign/daemon directory,
>     but I wanted to make sure.
>
>     Thanks,
>     Chris
>
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Cosign-discuss mailing list
>     Cos...@li...
>     <mailto:Cos...@li...>
>     https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>     <https://lists.sourceforge.net/lists/listinfo/cosign-discuss>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss

Re: [Cosign-discuss] cosign login with krb5 key (or tgt) possible?

[Brian R. <bd...@um...>]

Cosign is firmly tied to using a login & password against a Kerberos realm.
You would not be able to use a keytab or existing Kerberos ticket to
authenticate. The cookies are just random strings used to reference data
stored on the Cosign servers. They do not contain data, nor are they
derived from data.

On Sat, Nov 25, 2017 at 7:20 PM, Chris Hecker <ch...@d6...> wrote:

>
> I'm hoping the answer is 'no' for my current application, but is there a
> way for a user with a valid krb5 account on the kdc and a keytab file (or
> TGT) for that account to log into cosign without knowing the password used
> to make the key? In other words, there's no way to skip the plaintext
> password entry and pass a key or a TGT directly to cosign, right?
>
> Or, would it be possible to set the cookies correctly manually if the user
> has the key and/or a TGT for the key? It doesn't seem like it from looking
> at the code because then the corresponding cookie file wouldn't exist in
> the /var/cosign/daemon directory, but I wanted to make sure.
>
> Thanks,
> Chris
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>

[Cosign-discuss] cosign login with krb5 key (or tgt) possible?

[Chris H. <ch...@d6...>]

I'm hoping the answer is 'no' for my current application, but is there a
way for a user with a valid krb5 account on the kdc and a keytab file (or
TGT) for that account to log into cosign without knowing the password used
to make the key? In other words, there's no way to skip the plaintext
password entry and pass a key or a TGT directly to cosign, right?

Or, would it be possible to set the cookies correctly manually if the user
has the key and/or a TGT for the key? It doesn't seem like it from looking
at the code because then the corresponding cookie file wouldn't exist in
the /var/cosign/daemon directory, but I wanted to make sure.

Thanks,
Chris

[Cosign-discuss] CosignModule and Windows Server 2016, HTTP/2 SPDY

[Phil P. <pg...@pS...>]

For CosignModule to work on Windows Server 2016, we've needed to disable 
HTTP/2 (aka SPDY). This registry change/addition with a reboot has 
worked for us:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

EnableHttp2Tls REG_DWORD 0
EnableHttp2Cleartext REG_DWORD 0

-Phil

(Thanks for the find, Ron Rossman)

Re: [Cosign-discuss] Installing Cosign on Mac OSX 10.11 Server with SIP disabled

[Steve M. <ma...@um...>]

Yeah, I meant to follow up with this question (since it was my own question).

With SIP enabled on 10.11 (and 10.12), I had to do two things:

1)  install openssl (I used homebrew for this)

2)  the default “make install” command doesn’t work, so mod_cosign.so has to be grabbed out of:

cosign-<VERSION>/filters/apache2/.libs

and then put it a user-writeable location like /opt/local or /usr/local and referenced from there.

Hope that helps somebody!

- Steve


> On Sep 3, 2016, at 7:17 PM, Liam Hoekenga <li...@um...> wrote:
> 
> I think I've had to point it at a MacPorts install of OpenSSL.  If you look at config.log, I think the version that comes w OS X may be missing the .h files
> 
> Liam
> 
> On Friday, September 2, 2016, Steve Maser <ma...@um... <mailto:ma...@um...>> wrote:
> Hey all…
> 
> Simple question:   what needs to be modified to run “configure” on Mac OSX 10.11?
> 
> when I try it with System Integrity Protection *disabled* (using xCode 7.2.1 with the command line tools) and cosign 3.2.0, I get this:
> 
> ./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for a BSD-compatible install... /usr/bin/install -c
> checking build system type... i686-apple-darwin15.6.0
> checking host system type... i686-apple-darwin15.6.0
> checking for inet_ntoa in -lnsl... no
> checking for socket in -lsocket... no
> apache 1.3 not enabled
> checking for apache 2... using apxs2 as '/usr/sbin/apxs'
> apache 2 filter will be built
> lighttpd not enabled
> checking for krb... Kerberos found at /usr
> mysql not enabled
> checking for gss... /usr
> checking for ssl... configure: error: cannot find ssl libraries
> 
> 
> (trying it with SIP enabled, barely got anywhere…)
> 
> 
> I tried to search through the archives, but didn’t find anything explicit about this error with the ssl libraries.
> 
> Anybody have any suggestions?   And if they fixed this part, is there anything additional that needs modifying to make it work on 10.11?
> 
> Thanks!
> 
> - Steve
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss <https://lists.sourceforge.net/lists/listinfo/cosign-discuss>

[Cosign-discuss] Multiple Sites/Applications

[MICHELLE R. L. <mr...@ps...>]

I have been working on getting Cosign to integrate with our CRM system.  

The problem seems to be that there is a Default Web Site with 10 branches
under it, I get cosign to work however we also have a desktop app that now
has stopped working because it point to one of the subdirectories.

 

Default Web Site (crmcn-sbx-app.windom.outreach.psu.edu)

-          AppServer

-          AppServer_Trusted

-          Aspnet_client

-          Bizadmin

-          Calendar

-          Cmc.crm.sts

-          Cmc.crm.web

-          Cmc.crm.workspaces

-          MediaUpload

-          SMSWebService

-          TransmitTracker

 

The desktop Client points to the Application Server:
https://crmcn-sbx-app.windom.outreach.psu.edu/appserver/infoxmlserver.aspx

 

 

Re: [Cosign-discuss] Installing Cosign on Mac OSX 10.11 Server with SIP disabled

[Steve M. <ma...@um...>]

You might be right about this.   xCode 7.2.1 (the one offered for 10.10 from the AppStore) has ssl.h here:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/openssl/ssl.h

and

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/openssl/ssl.h



But xCode 7.3.1 (offered to 10.11) has it here:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-migrator/sdk/MacOSX.sdk/usr/include/openssl/ssl.h


Thoughts as to what I’d need to modify in the config so it would find this version?  (It looks like the Xcode 8 beta does not even have ssl.h anywhere within it…)

- Steve



> On Sep 3, 2016, at 7:17 PM, Liam Hoekenga <li...@um...> wrote:
> 
> I think I've had to point it at a MacPorts install of OpenSSL.  If you look at config.log, I think the version that comes w OS X may be missing the .h files
> 
> Liam
> 
> On Friday, September 2, 2016, Steve Maser <ma...@um... <mailto:ma...@um...>> wrote:
> Hey all…
> 
> Simple question:   what needs to be modified to run “configure” on Mac OSX 10.11?
> 
> when I try it with System Integrity Protection *disabled* (using xCode 7.2.1 with the command line tools) and cosign 3.2.0, I get this:
> 
> ./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for a BSD-compatible install... /usr/bin/install -c
> checking build system type... i686-apple-darwin15.6.0
> checking host system type... i686-apple-darwin15.6.0
> checking for inet_ntoa in -lnsl... no
> checking for socket in -lsocket... no
> apache 1.3 not enabled
> checking for apache 2... using apxs2 as '/usr/sbin/apxs'
> apache 2 filter will be built
> lighttpd not enabled
> checking for krb... Kerberos found at /usr
> mysql not enabled
> checking for gss... /usr
> checking for ssl... configure: error: cannot find ssl libraries
> 
> 
> (trying it with SIP enabled, barely got anywhere…)
> 
> 
> I tried to search through the archives, but didn’t find anything explicit about this error with the ssl libraries.
> 
> Anybody have any suggestions?   And if they fixed this part, is there anything additional that needs modifying to make it work on 10.11?
> 
> Thanks!
> 
> - Steve
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss <https://lists.sourceforge.net/lists/listinfo/cosign-discuss>

Re: [Cosign-discuss] Installing Cosign on Mac OSX 10.11 Server with SIP disabled

[Steve M. <ma...@um...>]

I know 10.11 has a slightly different version of ssl than 10.10, but it’s in the same location:

10.10.5 (current build):

tts10:cosign-3.2.0 root# which openssl
/usr/bin/openssl
tts10:cosign-3.2.0 root# openssl version
OpenSSL 0.9.8zg 14 July 2015

10.11.6 (current build):
tts11:include root# which openssl
/usr/bin/openssl
tts11:include root# openssl version
OpenSSL 0.9.8zh 14 Jan 2016

I hate to just dump log files, but this is what config.log gives me when I try this (as I don’t know what to look for where in all honesty — it’s been almost 2 years since I’ve done anything with cosign…):

spy:cosign-3.2.0 root# cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by cosign configure 3.2.0, which was
generated by GNU Autoconf 2.61.  Invocation command line was

  $ ./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss

## --------- ##
## Platform. ##
## --------- ##

hostname = (REDACTED)
uname -m = x86_64
uname -r = 15.6.0
uname -s = Darwin
uname -v = Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = Mach kernel version:
	 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64
Kernel configured for up to 4 processors.
4 processors are physically available.
4 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1 2 3
Primary memory available: 8.00 gigabytes
Default processor set: 246 tasks, 853 threads, 4 processors
Load average: 1.19, Mach factor: 2.79
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/sbin
PATH: /sbin
PATH: /Applications/Server.app/Contents/ServerRoot/usr/bin
PATH: /Applications/Server.app/Contents/ServerRoot/usr/sbin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1802: checking for gawk
configure:1832: result: no
configure:1802: checking for mawk
configure:1832: result: no
configure:1802: checking for nawk
configure:1832: result: no
configure:1802: checking for awk
configure:1818: found /usr/bin/awk
configure:1829: result: awk
configure:1888: checking for gcc
configure:1904: found /usr/bin/gcc
configure:1915: result: gcc
configure:2153: checking for C compiler version
configure:2160: gcc --version >&5
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
configure:2163: $? = 0
configure:2170: gcc -v >&5
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
configure:2173: $? = 0
configure:2180: gcc -V >&5
clang: error: argument to '-V' is missing (expected 1 value)
clang: error: no input files
configure:2183: $? = 1
configure:2206: checking for C compiler default output file name
configure:2233: gcc    conftest.c  >&5
configure:2236: $? = 0
configure:2274: result: a.out
configure:2291: checking whether the C compiler works
configure:2301: ./a.out
configure:2304: $? = 0
configure:2321: result: yes
configure:2328: checking whether we are cross compiling
configure:2330: result: no
configure:2333: checking for suffix of executables
configure:2340: gcc -o conftest    conftest.c  >&5
configure:2343: $? = 0
configure:2367: result: 
configure:2373: checking for suffix of object files
configure:2399: gcc -c   conftest.c >&5
configure:2402: $? = 0
configure:2425: result: o
configure:2429: checking whether we are using the GNU C compiler
configure:2458: gcc -c   conftest.c >&5
configure:2464: $? = 0
configure:2481: result: yes
configure:2486: checking whether gcc accepts -g
configure:2516: gcc -c -g  conftest.c >&5
configure:2522: $? = 0
configure:2621: result: yes
configure:2638: checking for gcc option to accept ISO C89
configure:2712: gcc  -c -g -O2  conftest.c >&5
configure:2718: $? = 0
configure:2741: result: none needed
configure:2803: checking for a BSD-compatible install
configure:2859: result: /usr/bin/install -c
configure:2877: checking build system type
configure:2895: result: i686-apple-darwin15.6.0
configure:2917: checking host system type
configure:2932: result: i686-apple-darwin15.6.0
configure:2958: checking for inet_ntoa in -lnsl
configure:2993: gcc -o conftest -g -O2   conftest.c -lnsl   >&5
ld: library not found for -lnsl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:2999: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "cosign"
| #define PACKAGE_TARNAME "cosign"
| #define PACKAGE_VERSION "3.2.0"
| #define PACKAGE_STRING "cosign 3.2.0"
| #define PACKAGE_BUGREPORT "co...@um..."
| /* end confdefs.h.  */
| 
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char inet_ntoa ();
| int
| main ()
| {
| return inet_ntoa ();
|   ;
|   return 0;
| }
configure:3017: result: no
configure:3029: checking for socket in -lsocket
configure:3064: gcc -o conftest -g -O2   conftest.c -lsocket   >&5
ld: library not found for -lsocket
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:3070: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "cosign"
| #define PACKAGE_TARNAME "cosign"
| #define PACKAGE_VERSION "3.2.0"
| #define PACKAGE_STRING "cosign 3.2.0"
| #define PACKAGE_BUGREPORT "co...@um..."
| /* end confdefs.h.  */
| 
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char socket ();
| int
| main ()
| {
| return socket ();
|   ;
|   return 0;
| }
configure:3088: result: no
configure:3138: result: apache 1.3 not enabled
configure:3146: checking for apache 2
configure:3194: result: apache 2 filter will be built
configure:3247: result: lighttpd not enabled
configure:3255: checking for krb
configure:3308: result: Kerberos found at /usr
configure:3367: result: mysql not enabled
configure:3376: checking for gss
configure:3393: result: /usr
configure:3563: checking for ssl
configure:3592: error: cannot find ssl libraries

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-apple-darwin15.6.0
ac_cv_c_compiler_gnu=yes
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=i686-apple-darwin15.6.0
ac_cv_lib_nsl_inet_ntoa=no
ac_cv_lib_socket_socket=no
ac_cv_objext=o
ac_cv_path_apxs2=/usr/sbin/apxs
ac_cv_path_install='/usr/bin/install -c'
ac_cv_path_krb=/usr
ac_cv_prog_AWK=awk
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_cc_c89=
ac_cv_prog_cc_g=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

ADDLDFLAGS=''
ADDLIBS=''
APACHECTL2='/usr/sbin/apachectl'
APACHECTL=''
APXS2='/usr/sbin/apxs'
APXS=''
AWK='awk'
CC='gcc'
CFLAGS='-g -O2'
CPP=''
CPPFLAGS=''
DEFS=''
ECHO_C='ECHO_N=''
ECHO_T=''
EGREP=''
EXEEXT=''
FILTERS=' filters/apache2'
FILTER_COMPILER_OPTS=''
FILTER_LINKER_OPTS=''
GREP=''
GSSINC='-I/usr/include'
GSSLDFLAGS='-L/usr/lib'
GSSLIBS='-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err'
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
KINC='-I/usr/include'
KLDFLAGS='-L/usr/lib'
KLIBS='-lkrb5 -lk5crypto -lcom_err'
KRBCGI='cosign.cgi'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LIGHTTPD_COSIGN_SRCDIR=''
LTLIBOBJS=''
MYSQLINC=''
MYSQLLDFLAGS=''
MYSQLLIBS=''
OBJEXT='o'
OPTOPTS=''
PACKAGE_BUGREPORT='co...@um...'
PACKAGE_NAME='cosign'
PACKAGE_STRING='cosign 3.2.0'
PACKAGE_TARNAME='cosign'
PACKAGE_VERSION='3.2.0'
PATH_SEPARATOR=':'
SHELL='/bin/sh'
UNIVERSAL_OPTOPTS=''
ac_ct_CC='gcc'
bindir='${exec_prefix}/bin'
build='i686-apple-darwin15.6.0'
build_alias=''
build_cpu='i686'
build_os='darwin15.6.0'
build_vendor='apple'
cosigncadir='/var/cosign/certs/CA'
cosigncert='/var/cosign/certs/cert.pem'
cosignconf='/usr/local/etc/cosign.conf'
cosigndb='/var/cosign/daemon'
cosignhost='cosign.example.edu'
cosignkey='/var/cosign/certs/key.pem'
cosignlogoutregex='http://.+\.example\.edu'
cosignlogouturl='http://cosign.example.edu'
cosignloopurl='http://cosign.example.edu/looping.html'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
filterdb='/var/cosign/filter'
frienddbhost='localhost'
frienddblogin='friend'
frienddbpasswd=''
host='i686-apple-darwin15.6.0'
host_alias=''
host_cpu='i686'
host_os='darwin15.6.0'
host_vendor='apple'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
keytabpath=''
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='NONE'
program_transform_name='s,x,x,'
proxydb='/var/cosign/proxy'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
subdirs=''
sysconfdir='${prefix}/etc'
target_alias=''
ticketcache='/ticket'

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_NAME "cosign"
#define PACKAGE_TARNAME "cosign"
#define PACKAGE_VERSION "3.2.0"
#define PACKAGE_STRING "cosign 3.2.0"
#define PACKAGE_BUGREPORT "co...@um..."
#define HAVE_AP_REGEX_H 1
#define HAVE_MOD_AUTHZ_HOST 1
#define APACHE2 1
#define KRB 1
#define GSS 1

configure: exit 1
spy:cosign-3.2.0 root# 


> On Sep 3, 2016, at 7:17 PM, Liam Hoekenga <li...@um...> wrote:
> 
> I think I've had to point it at a MacPorts install of OpenSSL.  If you look at config.log, I think the version that comes w OS X may be missing the .h files
> 
> Liam
> 
> On Friday, September 2, 2016, Steve Maser <ma...@um...> wrote:
> Hey all…
> 
> Simple question:   what needs to be modified to run “configure” on Mac OSX 10.11?
> 
> when I try it with System Integrity Protection *disabled* (using xCode 7.2.1 with the command line tools) and cosign 3.2.0, I get this:
> 
> ./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for a BSD-compatible install... /usr/bin/install -c
> checking build system type... i686-apple-darwin15.6.0
> checking host system type... i686-apple-darwin15.6.0
> checking for inet_ntoa in -lnsl... no
> checking for socket in -lsocket... no
> apache 1.3 not enabled
> checking for apache 2... using apxs2 as '/usr/sbin/apxs'
> apache 2 filter will be built
> lighttpd not enabled
> checking for krb... Kerberos found at /usr
> mysql not enabled
> checking for gss... /usr
> checking for ssl... configure: error: cannot find ssl libraries
> 
> 
> (trying it with SIP enabled, barely got anywhere…)
> 
> 
> I tried to search through the archives, but didn’t find anything explicit about this error with the ssl libraries.
> 
> Anybody have any suggestions?   And if they fixed this part, is there anything additional that needs modifying to make it work on 10.11?
> 
> Thanks!
> 
> - Steve
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss

Re: [Cosign-discuss] Installing Cosign on Mac OSX 10.11 Server with SIP disabled

[Liam H. <li...@um...>]

I think I've had to point it at a MacPorts install of OpenSSL.  If you look
at config.log, I think the version that comes w OS X may be missing the .h
files

Liam

On Friday, September 2, 2016, Steve Maser <ma...@um...> wrote:

> Hey all…
>
> Simple question:   what needs to be modified to run “configure” on Mac OSX
> 10.11?
>
> when I try it with System Integrity Protection *disabled* (using xCode
> 7.2.1 with the command line tools) and cosign 3.2.0, I get this:
>
> ./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for a BSD-compatible install... /usr/bin/install -c
> checking build system type... i686-apple-darwin15.6.0
> checking host system type... i686-apple-darwin15.6.0
> checking for inet_ntoa in -lnsl... no
> checking for socket in -lsocket... no
> apache 1.3 not enabled
> checking for apache 2... using apxs2 as '/usr/sbin/apxs'
> apache 2 filter will be built
> lighttpd not enabled
> checking for krb... Kerberos found at /usr
> mysql not enabled
> checking for gss... /usr
> checking for ssl... configure: error: cannot find ssl libraries
>
>
> (trying it with SIP enabled, barely got anywhere…)
>
>
> I tried to search through the archives, but didn’t find anything explicit
> about this error with the ssl libraries.
>
> Anybody have any suggestions?   And if they fixed this part, is there
> anything additional that needs modifying to make it work on 10.11?
>
> Thanks!
>
> - Steve
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Cosign-discuss mailing list
> Cos...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>

Re: [Cosign-discuss] Installing Cosign on Mac OSX 10.11 Server with SIP disabled

[Yadin F. <yx...@ps...>]

Well, given cosign hasn't been updated in 4 years, my guess would be the 
script isn't compatible with 10.11 or it's not compatible with newer SSL 
versions.
I didn't realize it hadn't been touched in that long.  Maybe it doesn't 
need to be, but in context of other open source stuff that has died over 
the years it makes me hesitant.
That said, I also see that ssl is not enabled by default in apache2 on 
Mac OS.  Have you enabled it?  If not, it could be that the configure 
script can't find SSL because apache is not loading it.

https://getgrav.org/blog/mac-os-x-apache-setup-ssl

-------------------------------------------------------------------
   Yadin Flammer - Systems Administrator
   College of Arts & Architecture, Penn State University
   220 Borland Building              Office Phone: 814-865-0990
   University Park, PA 16802         Dept. Phone:  814-865-1571
   Email: yx...@ps...               Dept. Fax:    814-863-6227

On 9/3/16 9:42 AM, Steve Maser wrote:
> That’s part of what is confusing me.   I get what you say I should get:
>
> mockingbird:~ root# which openssl
> /usr/bin/openssl
> mockingbird:~ root# openssl version
> OpenSSL 0.9.8zh 14 Jan 2016
> mockingbird:~ root#
>
>
> - Steve
>
>
>> On Sep 3, 2016, at 12:20 AM, Yadin Flammer <yx...@ps...> wrote:
>>
>> Never compiled on a Mac, but your log says it can't find ssl libraries, which is curious since they are built in to the OS.
>> If you do "which openssl" is should say it's in /usr/bin/openssl
>> If you do "openssl version" it should say it's OpenSSL 0.9.8zh 14 Jan 2016
>>
>> If not, somehow your system is damaged?
>>
>>   
>> -------------------------------------------------------------------
>>    Yadin Flammer - Systems Administrator
>>    College of Arts & Architecture, Penn State University
>>    220 Borland Building              Office Phone: 814-865-0990
>>    University Park, PA 16802         Dept. Phone:  814-865-1571
>>    Email:
>> yx...@ps...               Dept. Fax:    814-863-6227
>> On 9/2/16 11:57 PM, Steve Maser wrote:
>>> Hey all…
>>>
>>> Simple question:   what needs to be modified to run “configure” on Mac OSX 10.11?
>>>
>>> when I try it with System Integrity Protection *disabled* (using xCode 7.2.1 with the command line tools) and cosign 3.2.0, I get this:
>>>
>>> ./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss
>>> checking for gawk... no
>>> checking for mawk... no
>>> checking for nawk... no
>>> checking for awk... awk
>>> checking for gcc... gcc
>>> checking for C compiler default output file name... a.out
>>> checking whether the C compiler works... yes
>>> checking whether we are cross compiling... no
>>> checking for suffix of executables...
>>> checking for suffix of object files... o
>>> checking whether we are using the GNU C compiler... yes
>>> checking whether gcc accepts -g... yes
>>> checking for gcc option to accept ISO C89... none needed
>>> checking for a BSD-compatible install... /usr/bin/install -c
>>> checking build system type... i686-apple-darwin15.6.0
>>> checking host system type... i686-apple-darwin15.6.0
>>> checking for inet_ntoa in -lnsl... no
>>> checking for socket in -lsocket... no
>>> apache 1.3 not enabled
>>> checking for apache 2... using apxs2 as '/usr/sbin/apxs'
>>> apache 2 filter will be built
>>> lighttpd not enabled
>>> checking for krb... Kerberos found at /usr
>>> mysql not enabled
>>> checking for gss... /usr
>>> checking for ssl... configure: error: cannot find ssl libraries
>>>
>>>
>>> (trying it with SIP enabled, barely got anywhere…)
>>>
>>>
>>> I tried to search through the archives, but didn’t find anything explicit about this error with the ssl libraries.
>>>
>>> Anybody have any suggestions?   And if they fixed this part, is there anything additional that needs modifying to make it work on 10.11?
>>>
>>> Thanks!
>>>
>>> - Steve
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Cosign-discuss mailing list
>>>
>>> Cos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss

Re: [Cosign-discuss] Installing Cosign on Mac OSX 10.11 Server with SIP disabled

[Steve M. <ma...@um...>]

That’s part of what is confusing me.   I get what you say I should get:

mockingbird:~ root# which openssl
/usr/bin/openssl
mockingbird:~ root# openssl version
OpenSSL 0.9.8zh 14 Jan 2016
mockingbird:~ root# 


- Steve


> On Sep 3, 2016, at 12:20 AM, Yadin Flammer <yx...@ps...> wrote:
> 
> Never compiled on a Mac, but your log says it can't find ssl libraries, which is curious since they are built in to the OS.
> If you do "which openssl" is should say it's in /usr/bin/openssl
> If you do "openssl version" it should say it's OpenSSL 0.9.8zh 14 Jan 2016
> 
> If not, somehow your system is damaged?
> 
>  
> -------------------------------------------------------------------
>   Yadin Flammer - Systems Administrator
>   College of Arts & Architecture, Penn State University
>   220 Borland Building              Office Phone: 814-865-0990
>   University Park, PA 16802         Dept. Phone:  814-865-1571
>   Email: 
> yx...@ps...               Dept. Fax:    814-863-6227
> On 9/2/16 11:57 PM, Steve Maser wrote:
>> Hey all…
>> 
>> Simple question:   what needs to be modified to run “configure” on Mac OSX 10.11?
>> 
>> when I try it with System Integrity Protection *disabled* (using xCode 7.2.1 with the command line tools) and cosign 3.2.0, I get this:
>> 
>> ./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss
>> checking for gawk... no
>> checking for mawk... no
>> checking for nawk... no
>> checking for awk... awk
>> checking for gcc... gcc
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables... 
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking build system type... i686-apple-darwin15.6.0
>> checking host system type... i686-apple-darwin15.6.0
>> checking for inet_ntoa in -lnsl... no
>> checking for socket in -lsocket... no
>> apache 1.3 not enabled
>> checking for apache 2... using apxs2 as '/usr/sbin/apxs'
>> apache 2 filter will be built
>> lighttpd not enabled
>> checking for krb... Kerberos found at /usr
>> mysql not enabled
>> checking for gss... /usr
>> checking for ssl... configure: error: cannot find ssl libraries
>> 
>> 
>> (trying it with SIP enabled, barely got anywhere…)
>> 
>> 
>> I tried to search through the archives, but didn’t find anything explicit about this error with the ssl libraries.
>> 
>> Anybody have any suggestions?   And if they fixed this part, is there anything additional that needs modifying to make it work on 10.11?
>> 
>> Thanks!
>> 
>> - Steve 
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Cosign-discuss mailing list
>> 
>> Cos...@li...
>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> 

[Cosign-discuss] Installing Cosign on Mac OSX 10.11 Server with SIP disabled

[Steve M. <ma...@um...>]

Hey all…

Simple question:   what needs to be modified to run “configure” on Mac OSX 10.11?

when I try it with System Integrity Protection *disabled* (using xCode 7.2.1 with the command line tools) and cosign 3.2.0, I get this:

./configure --enable-apache2=/usr/sbin/apxs --enable-krb --with-gss
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... i686-apple-darwin15.6.0
checking host system type... i686-apple-darwin15.6.0
checking for inet_ntoa in -lnsl... no
checking for socket in -lsocket... no
apache 1.3 not enabled
checking for apache 2... using apxs2 as '/usr/sbin/apxs'
apache 2 filter will be built
lighttpd not enabled
checking for krb... Kerberos found at /usr
mysql not enabled
checking for gss... /usr
checking for ssl... configure: error: cannot find ssl libraries


(trying it with SIP enabled, barely got anywhere…)


I tried to search through the archives, but didn’t find anything explicit about this error with the ssl libraries.

Anybody have any suggestions?   And if they fixed this part, is there anything additional that needs modifying to make it work on 10.11?

Thanks!

- Steve