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

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

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.

You currently have a different (subtle) problem.

You have changed the CA to include the "critical" bit. That's good - 
but it is now a whole new CA with a new signing key.

The server certificate contains a link to the CRL which is 
URI:http://drcmr.dk/root.crl.

That CRL exists, and is in its validity timespan, but it is signed by 
your *previous* incarnation of the CA.

openssl only checks CRLs when explicitly told to. Your commandline did 
not - so everything looks in order. Our checks do - and the 
verification fails:

swinter@aragorn:~/scratch> openssl verify -CApath chain/ server.pem 
server.pem: OK

swinter@aragorn:~/scratch> openssl verify -CApath chain/ -crl_check 
server.pem 
server.pem: C = DK, ST = Copenhagen, L = Hvidovre, O = DRCMR Eduroam, CN = 
drcmr.dk, emailAddress = 
sysadmin AT drcmr.dk
error 8 at 0 depth lookup:CRL signature failure
140369048077968:error:0407006A:rsa 
routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:102:
140369048077968:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding 
check failed:rsa_eay.c:797:
140369048077968:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP 
lib:a_verify.c:233:

The smoking gun is "CRL signature failure".

When you issue a new CRL for the new CA and put it in the same place,
the checks will (well, might :-) ) pass.

(curious about the "chain" subdir? When checking more than one
trust-relevant file, all those relevant files need to be put in
a separate directory, and in that directory, the command "c_rehash ."
needs to be executed. Then, that directory can referenced with -CApath.
All files in the directory need to be in PEM format (note that your CRL
rightly is in DER encoding; you need to convert it to PEM first)

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

If you are using FreeRADIUS, it's quite common to fall for the config
error that causes this:

You do NOT need to set the ca_file or ca_path parameters. They are only
relevant for EAP-TLS client certificate verification. If you do set them,
FreeRADIUS makes use of the information, realises that the CA matches the
server cert's chain, and generously includes it in the EAP conversation.

And one last point: it is sufficient to change the CN; it is common
practice to keep the O equal. Currently, both differ, which is more
than enough. A little bit less difference would still do :-)

Greetings,

Stefan Winter

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


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