client-certificate
2 TopicsSSL connection error, client certificate validation issue - RSASSA-PSS signature algorithm support?
2-way SSL VIP with client certificate "required", we are getting SSL connection errors. The LTM log contains: SSL Handshake failed for TCP from 10.20.15.156:57757 to 172.20.104.11:443 The CA chain and leaf certs are all issued by Windows certificate svcs. I believe the problem is the use of the RSASSA-PSS signature algorithm in the certs. When I upload the CA chain and a client cert to the F5 and manually do an "openssl verify -purpose sslclient -verbose -CAfile ./ca.cer ./client.cer", I get error messages as follow: [root@lb:Active:Changes Pending] ~ openssl verify -purpose sslclient -verbose -CAfile ./ca.cer ./client.cer client.cer: /DC=local/DC=ad/OU=People/CN=Bucci, David/emailAddress=David.Bucci@ad.net error 7 at 0 depth lookup:certificate signature failure 10346:error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm:a_verify.c:152: And my client cert does in fact have signature algorithm set to RSASSA-PSS. In order to prove to myself it's the RSASSA-PSS signature algorithm, I used a different CA chain/child cert, where the intermediate CA cert uses that signature algorithm, but the child cert uses vanilla sha1rsa, and in that case, the error statement changes to "error 7 at 1 depth" ... which I believe means the child cert was fine, but then when it traversed up 1 level to the intermediate CA cert, the problem occurred. When I upload the exact same ca.cer and client.cer to a Red Hat box and run the same command, the certificate verifies fine -- as do the other child/CA chain, where the child has sha1rsa, but the intermediate CA has the RSASSA-PSS. That RHEL box is running openssl version 1.0.1e-fips 11 Feb 2013, while the F5 is at 11.4.1, with openssl version 0.9.8y 5 Feb 2013. Does that seem like a cogent analysis? Are there any other steps it would make sense to take to further verify the root issue? And, if the analysis is correct, is there any way to get the F5 to accept RSASSA-PSS as a signature algorithm? thx!889Views0likes8CommentsClient-Certificate and IP-Whitelisting via Policy or iRule?
We have a requirement to verify for a valid client-certificate (not expired and issued from a trusted CA), but also accept a bypass if the source-IP is trusted. I have the following questions for the two different configuration options: Policy In the condition section for "SSL certificate" it says "common name with index", is this the number of the certificate (same as the iRule command "SSL::cert <index>")? Does this mean I can only verify the standard CN of it? In the documentation it's only mentioned "Inspects the properties of an SSL certificate", which sounds to me I can also verify e.g. issuer name, serial number of the issuer or expiration dates. So which value do I have to enter here? Or in other words, how can I check that the presented client-certificate is really issued from a trusted CA and not from a fake CA with the same CN? Assuming the first question can be answered positively, is it correct, that I simply create two rules based on "first match" to forward traffic (first rule for client-cert check, second rule for IP-whitelisting) and if none of the rules are matching, traffic will be blocked? Assuming above mentioned policy-setup is not possible, I would configure the client-cert check within an iRule. iRule Is the option "Trusted Certificate Authorities" from the clientSSL-profile used if I set "Client Certificate" to request? And if so, do I have to use any special iRule commands to do this? If the list of trusted CA from the clientSSL-profile can't be used within the iRule, which other commands best "simulate" this kind of check? I mean a string comparison for the issuer CN name is not a good option, because I can create my own CA, if I know the allowed CA-name. Is the serial number a better option? Or in other words, same question as above,how can I check that the presented client-certificate is really issued from a trusted CA and not from a fake CA with the same CN? The IP-whitelisting can be simply added in an else branch then, right? Thank you! Regards Stefan 🙂Solved2KViews1like7Comments