We had to add each CA cert to the EAPTLS_CAPath with both the old and
the new hash and limit the authentication using
EAPTLS_CertificateVerifyHook as Heikki suggested.
To find out the two hashes use 'openssl x509 -in CA.pem -noout
-issuer_hash_old' and -issuer_hash and create symlinks named $hash.0 and
$oldhash.0 in the EAPTLS_CAPath directory to the CA.pem file.
This also allows to check the subject for specific OU's etc.
Best regards, Alex
On 2017-04-20 09:44, Heikki Vatiainen wrote:
On 19.4.2017 17.17, Philip Brusten wrote:
Assume you have a PKI like:
root CA
- intermediate CA 1
- issuing CA 1
- intermediate CA 2
- issuing CA 2
If you only want to trust endpoint certificates for EAP-TLS issued by
"issuing CA 2", would it be sufficient to *only* trust "issuing CA 2"
in EAPTLS_CAFile?
Possibly yes. I think that in X.509 the trusted CAs, or trust anchors
as they are called, do not need to have subject and issuer that is
equal. This is what the current practice is with root CA certificates
(you need to put something in issuer so own name is used).
In other words, you could try using any CA certificate as a trust
anchor by configuring it as trusted. What is unsure, the "possibly"
part, refers to the question if the software can be configured to do so.
What comes to Radiator, the configuration parameters affect what is
passed to Net::SSLeay which then talks directly to
OpenSSL/LibreSSL/etc. This means the TLS library manual could also be
helpful to see what and how to configure. There's also the question of
different library versions having different behaviour.
In short: you could test and see if it works.
In addition to this, you could consider EAPTLS_CertificateVerifyHook
to see that the client certifcate's issuer is "issuing CA 2". This
could provide a good belt + suspenders configuration even if trusting
"issuing CA 2" would work by itself.
Or is it required to trust the entire chain: "root CA" +
"intermediate CA 2" + "issuing CA 2"?
If you do the latter and a supplicant device has a certificate issued
by "issuing CA 1" and sends its entire certificate chain up to the
root CA during the handshake, will it be validated as well?
I'd say there's potential for this to happen. In this case you could
use the hook I mentioned above to see that everything else except of
certificates issued by "issuing CA 2" get grounded and rejected.
The documentation
https://www.open.com.au/radiator/ref/EAPTLS_CAFile.html#EAPTLS_CAFile
is not entirely clear on that.
I think we'd need to say that TLS library manual would be the
canonical source of information for these options.
Please let the list know how it goes!
Thanks,
Heikki
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
_______________________________________________
radiator mailing list
[email protected]
http://lists.open.com.au/mailman/listinfo/radiator
