I have a SA with Network Connect configured to authenticate user only by certificate. It work perfectly with a certificate with an old certificate authority, but when I want to change the authentication with our new CA (with an intermediate CA), we always got : "Invalid or expired certificate". If in trusted clients CA, I remove the use of CRL, we can connect.
We don't want to not check CRL ! If I update CRL, by clicking update in CRL Settings, no error and got message 'Last result: Success, same CRL' with the date of last update updated.
See in log :
SYS30734 2013-03-28 17:58:11 - SSL-XXX2 - [127.0.0.1] System() - Downloaded Identical CRL (920 bytes) from 'http://pki.xxxxx-yyyy.fr/AC_Personnel/crl/crl-1.crl'
When the auth fail I got this log
AUT24604 2013-03-28 18:29:30 - SSL-XXX2 - [10.1.25.39] System() - SSL negotiation failed while client at source IP '5.X.Y.39' was trying to connect to '194.xxx.yyy.50'. Reason: ''
I remove all certificats restriction, without succes. Our CRL is available, the SA don't have any droped packet on firewall.
Anybody have an idea why I got this problem ?
SA is a 4500 with 7.3R3 (build 23377)
If there are no issues with downloading the crl on the SA device and it works without it, but fails with the CRL installed on the SA, most likely the certificate you are using is revoked. Can you check the crl list to see if the serial number of the certificate you are using is revoked?
Under CRL Checking options what is the CRL Distribution point selected (CDP)
CDP specified in Trusted Client CA
CDP Specified in Client certificate
If the Certificate is issued from a interim CA this would have a different CDP than the one in the interim CA.
Try setting this to CDP Specified in Client certificate or manually you can configure the CDP looking at client certtificate.
The certificate that I use is valid and not revoked, I use it to authenticate in an another system.
I try to change the CDP : manually, in client certificate and in trusted ca, without any success.
Did the certificate need a special "key usage" ?
I analyse the SSL stream with wireshark and decode it with the private key of the SA, and I see, that the communication switch to EAP, and after I reconize a TTLS authentication, and I can see the purpose of knowed and allowed CA. My pulse client purpose the good certificate and give the entire certificate chaine (CA, subca and end entitity certificate) after that I can't decode and don't know what happend.
The certificate does not need any specific key usage.
To be 100% of the issue, JTAC will need to increase debug logging on the SA with certificate event codes to help determine why the SA is failing. Do you have a current case open for this issue? If so, please provide the case number.
I Have a ticket with the JTAC, but they close it, because I was in Holidays...
I have a question : did the SA 4500 with firmware release 7.3R3 support certificate with Signature Algorithm: sha256WithRSAEncryption ?
Here a extract of the root CA. The only difference between client and CA certificats is the size of the private key : 4096 for CA and 2048 for client.
$ openssl x509 -in VilledeMarseilleAutoriteRacine.crt -inform DER -noout -text
Version: 3 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=FR, ST=PACA, L=Marseille, O=Ville de Marseille, OU=0002 21130055300016, CN=Ville de Marseille - Autorite Racine
Not Before: Mar 5 09:57:05 2013 GMT
Not After : Mar 6 09:57:05 2033 GMT
Subject: C=FR, ST=PACA, L=Marseille, O=Ville de Marseille, OU=0002 21130055300016, CN=Ville de Marseille - Autorite Racine
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Exponent: 65537 (0x10001)
X509v3 Subject Key Identifier:
X509v3 Basic Constraints: critical
X509v3 Authority Key Identifier:
X509v3 Certificate Policies:
Policy: X509v3 Any Policy
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
SHA256 is supported in 7.3 and should be okay. If you want, you can try upgrading to the latest release of 7.4 as openssl version would be upgraded. This may or may not fix your issue, but may be worth a try.
To root cause the issue, JTAC will need the debug log enabled with the proper certificate event codes. Can you please open a new case or request to re-open the existing case so we can gather the proper logs?
I can see the jtac rep has already updated you on the data we need. The most important log will be enabling the debug logging, replicate the issue and taking the system snapshot included the debug log. Once you've attached the logs, I can review this and provide you feedback. If you have any questions, please feel free to contact jtac support.