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

[Stefan Winter <stefan.winter AT restena.lu>]

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
>>
> 
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0x8A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature