The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Torkil Svensgaard <torkil AT drcmr.dk>]

Hi

Thanks for the tips =)

However, I changed the O for the server cert to something different, so 
they are no longer equal, but I'm still getting the same error in the 
CAT test tool. Files attached.

I'm also curious why the tool warns that the certificate chain contains 
the CA root cert. As far as I can see the CA root cert is not included 
in server.pem, so I'm unsure how to fix that?

Thanks,

Torkil

On 09/03/2015 03:51 PM, Stefan Winter wrote:
> Hello,
>
> > I'm not using any intermediate CA, I'm signing the server certificate
> > with the root CA. I've also changed the CN of the server cert so it's no
> > longer the same CN as the CA cert, and that seemed to make the second
> > error go away for a few iterations but alas.
>
> Hm. I don't think it's allowed for a CA and server cert to share the
> same name. The CN can be identical, but at least one of the other fields
> then needs to be different (i.e. C (country) O (organisation) or any of
> the other things you were asked during certificate creation).
>
> If they are all equal, the PKI world considers the server-cert
> self-signed by itself
> (Definition of self-signed is: "Issuer" and "Subject" are the same)
>
> Now, in your server certificate, those two are the same, but the signing
> key is actually *not* matching the server cert itself.
>
> I haven't encountered this situation before, and am scratching my head
> as to how we should handle it.
>
> > openssl verify -CAfile ca.pem server.pem
> > server.pem: OK
>
> I do have an explanation why this works on the command-line, but am not
> 100% sure.
>
> If your openssl is recent enough, it will try an exhaustive search for
> trust roots and not give up if its first attempt failed. openssl may
> have tried server-cert self-signed first (fails, wrong private key
> signed cert) but then tried the *other* cert with the same name but a
> different private key - the one you designated as trusted.
>
> It's quite possible that our openssl on the server is less recent and
> does not include this recent optimisation.
>
> In any case, you can avoid quite some trouble by separating the names of
> CA and server cert :-)
>
> One extra hint: up until recently, the CA cert generation scripts in
> FreeRADIUS were slightly wrong, and your CA has the same error. The
> "basicConstraints: CA=TRUE" extension must be marked as critical in CAs.
>
> The issue was fixed in FreeRADIUS 3.0.9, but you can easily backport it
> into your own CA generator script. See here:
>
> https://github.com/FreeRADIUS/freeradius-server/commit/812f7d63fe5ca32bab61eefeb974aded80e27b7e
>
> https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/certs/ca.cnf
>
> Greetings,
>
> Stefan Winter
>
> > Any suggestions would be appreciated,
> >
> > Torkil
> >
> > On 09/03/2015 08:21 AM, Torkil Svensgaard wrote:
> > > On 09/03/2015 05:51 AM, Stefan Winter wrote:
> > > > Hello,
> > > >
> > > > > I'm in the process of setting up my institutions IdP and I'm getting
> > > > > the following error when doing the live login test:
> > > > >
> > > > > "
> > > > > Test FAILED: authentication succeded. Some configuration errors were
> > > > > observed; the list is below.
> > > > > ...
> > > > > The server certificate could not be verified to the root CA you
> > > > > configured in your profile!
> > > > > "
> > > > >
> > > > > I'm using self signed keys and the server certificate seems to verify
> > > > > as it should:
> > > > >
> > > > > "
> > > > > # openssl verify -CAfile ca.pem server.pem
> > > > > server.pem: OK
> > > > > "
> > > > >
> > > > > Is the error misleading or did I misunderstand something?
> > > >
> > > > We haven't had false alerts with that one yet, so I'd think there is
> > > > something wrong/a bit special with your setup.
> > > >
> > > > Did you mean to say self-signed *certificates*? I don't know what
> > > > self-signed *keys* would be.
> > >
> > > Indeed
> > >
> > > > If you did mean self-signed certs - that term is usually used when the
> > > > CA cert is identical to the server certificate. You have two different
> > > > file names in your command-line. So, is the CA different from the
> > > > server?
> > >
> > > As you may have guessed I'm not that familiar with certificates, so
> > > self-signed might not be the right word. I thought I created a CA and
> > > used that to sign a server certificate (filching commands from the
> > > bootstrap script that comes with Freeradius).
> > >
> > > > Did you have any other errors or warnings besides this one?
> > >
> > > Yes,
> > >
> > > Test partially successful: a bidirectional RADIUS conversation with
> > > multiple round-trips was carried out, and ended in an Access-Reject as
> > > planned. Some configuration errors were observed; the list is below.
> > >
> > >            The certificate chain includes the root CA certificate. This
> > > does not serve any useful purpose but inflates the packet exchange,
> > > possibly leading to more round-trips and thus slower authentication.
> > >            At least one certificate did not contain any BasicConstraints
> > > extension; which makes it unclear if it's a CA certificate or end-entity
> > > certificate. At least Mac OS X 10.8 (Mountain Lion) will not validate
> > > this certificate for EAP purposes!
> > >            The server certificate did not include a CRL Distribution
> > > Point, creating compatibility problems with Windows Phone 8.
> > >            The server certificate could not be verified to the root CA
> > > you configured in your profile!
> > >            The configured EAP server name matches either the CN or a
> > > subjectAltName:DNS of the incoming certificate; best current practice is
> > > that the certificate should contain the name in BOTH places.
> > >
> > > I believe I will be able to fix those since the problems are described
> > > in your documentation, but I was unsure about the CA one.
> > >
> > > > Finally, it would help if you could attach the CA cert and server cert
> > > > so I can run some tests of my own
> > >
> > > Here you go.
> > >
> > > Thanks,
> > >
> > > Torkil


--
Torkil Svensgaard
Sysadmin
MR-Forskningssektionen, afs. 714
DRCMR, Danish Research Centre for Magnetic Resonance
Hvidovre Hospital
Kettegård Allé 30
DK-2650 Hvidovre
Denmark
Tel: +45 386 22828
E-mail: 
torkil AT drcmr.dk

Attachment: ca.pem
Description: application/x509-ca-cert

Attachment: server.pem
Description: application/x509-ca-cert