Forum Discussion
Xavier_Gillmann
Nimbostratus
NimbostratusCerts chains and authenticate depth...
Hi everybody,
I'm currently encountering problems with (client) certificate validation: when the client registers all certificate chain in its browser, this one (at least IE) submits all the chain when negociating with BigIP... which seems to provoque validation failure on BigIP
... well at least this how I understand the following logs
Code:
when CLIENTSSL_CLIENTCERT {
log LOCAL0.debug "nbr certs: [SSL::cert count] verifyResult: [SSL::verify_result] // [X509::verify_cert_error_string [SSL::verify_result]]"
set i 0
while {$i < [SSL::cert count]} {
log LOCAL0.debug "[X509::subject [SSL::cert $i]]"
incr i
}
Log:
Sep 15 11:30:40 tmm tmm[716]: 01260014:4: Peer cert verify error: unsupported certificate purpose (depth 0; cert /O=...(the Root CA)...)
Sep 15 11:30:40 tmm tmm[716]: Rule sslSymDEV : nbr certs: 3 verifyResult: 26 // unsupported certificate purpose
Sep 15 11:30:40 tmm tmm[716]: Rule sslSymDEV : /C=...(my cert)...
Sep 15 11:30:40 tmm tmm[716]: Rule sslSymDEV : /C=...(the signing CA)
Sep 15 11:30:40 tmm tmm[716]: Rule sslSymDEV : /O=...(the Root)
Of course, when my client do not register the all chain, the only submitted certificate is its own ... and the verification goes right (as that one can be used for authentication)...
Log:
Sep 15 11:46:14 tmm tmm[716]: Rule sslSymDEV : nbr certs: 1 verifyResult: 0 // ok
Sep 15 11:46:14 tmm tmm[716]: Rule sslSymDEV : /C=... (my cert) ...
I tried to set the authenticate depth... but it do no seem to have any effect.
Does anybody have an idea of what I could do wrong?
Thanks in advance,
Xavier
Carla_Molenda_1We had a similar problem where we received "unsupported certificate purpose" with the certificate authority listed as the failing certificate. The problem was in the code - it did not understand part of the encoding in the CA certificate. F5 created a hot fix for us. If you are not receivng failures just submitting the client cert then your problem is also likely one of the CA certs.
Xavier_GillmannHello,
Thanks for this response... it took me a while to reply.
I have to admit that your explanation did not really suite me at first glance: I'm used to first suspect what I do... but in this case, I turned the problem in many directions, read all possible documentation, questionning everything I do... without success.
...So I guess I'm facing the same problem as you!
Did you recieve a hot fix number... do you have any follow up for it?
Thank you for your help,
Xavier
Steve_Brockman_Fyi, I just ran into this problem today (unsupported certificate purpose) and thought I would post my solution. Maybe it will help someone else in the future!
It appears that our client certificates were requested as "Server Authentication Certificates" which cannot be used to present from a client to the F5 (during our 2-way SSL connection)
Once I re-requested the certificates properly this error went away!- Matt_Duguid_589Thanks very much your post did help us 7 years down the track :) We are testing a solution where we automatically deploy client authentication certificates to iOS/Andriod devices via Microsoft Intune/NDES, these are presented from "F5 Edge Client 2.0.4 (7060.2014.1006.1)" to "F5 Appliance 11.4" to connect via VPN. We were failing with the following in the SSL debug logs of the F5 Appliance, ------------------------- May 20 13:20:40 DEVICEX debug tmm[17839]: 01260006:7: Peer cert verify error: unsupported certificate purpose (depth 0; cert /CN=USERX) May 20 13:20:40 DEVICEX debug tmm[17839]: 01260009:7: Connection error: ssl_shim_vfycerterr:2912: unsupported certificate purpose (42) ------------------------- On the ADCS certificate template the "intended purpose" of "server authentication" had been enabled in addition to "client authentication". As soon as we removed the "server authentication" and reissued the certificates our issue went away as well and access worked. MD
- Steve_Brockman_Hello again,
We are revisiting this issue. We currently think it is a bug in the F5 to reject certificates in a 2-way SSL connection (that were issued by the CA as type "Server") when the server is acting as a client to another VS.
Can anyone verify/answer this?
Thanks!
Steve - Steve_Brockman_Sorry to repost,
But this seems strange that F5 rejects SSL connections (during a 2-way SSL connection) if the certificate presented is of type "Server." I have proven that a simple Java (JSSE) application that presents a "ServerAuth" certificate during a connection to a VS is being rejected by F5. Whereas, certificates issued as "Client" are allowed. But this presents a big problem because what if a server is running our application and wishes to connect to another cluster of servers behind the VS ??
F5 support is claiming this is not a bug.
I checked the TLS, SSLv3 and SSLv2 specs and nowhere does it specify that certificates must be rejected based on their type.
Can anyone confirm/contradict this?
Thanks,
Steve