Dear helpful people,
The problem is now solved by a workaround based on a new CAPF certificate.
That is that.
Concerning the discussion here, i (representing my supervisor) would like to
pinpoint 2 facts that arouse:
First and foremost the attached cacert.capf.pem is based on a Cisco __System
generated__ CSR and results in a certificate with the attributes:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage: critical
TLS Web Server Authentication
This very certificate is than used by the Cisco __system__ to issue
telephone/end-entity certificates in the likes of the attached
SEPxxxxxxx-L1.pem. These end-entity certificates have the following
attributes:
X509v3 Key Usage
Digital Signature, Key Encipherment
X509v3 Extended Key Usage
TLS Web Server Authentication, TLS Web Client Authentication, IPSec End
System
This is just wrong and we know that. But the Cisco System does it anyway.
Despite being wrong it is also absolutely irrelevant, because FreeRADIUS
retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entity
certifcate is ever seen.
We now have a very plain cacert.capf.pem. It only shows the following
attributes:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
and things work.
So to sum up: there is a mistake, that we know of, but really it is not in
our hands to change it. And we do not need to change it, because it is of no
concern to the problem at hand.
Secondly the presented cacert.capf.pem is (by itself) a valid certificate.
It does not present a mistake. We should also not need to change it - but we
do. Why? Having read all the discussion i do not know why. It is a CA
certificate and Cisco somehow restricts this CA certificate to a certain
chosen purpose. It is also ok to issue an intermediate CA certificate with
pathlen=5 and then issue right beneath it a intermediate CA certificate with
pathlen=0 instead of 4 to further restrict.
Restriction is a tool to reach more secure environments. The keyUsage
attributes are a way to use the tool of restriction. OpenSSL should not
interfere at this point.
This is my take on this topic.
I do thank you very much for your help and effort. Even if some of you see
the topic different, i like the fact that we discussed this really vividly.
Robert
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
