ssl_shim_vfycerterr:4539: application verification failure
Hi, after the Announcement regarding RSA vulnerability two weeks ago, we updated one of our BigIP from 11.5.3 to 12.1.2 HF2. We still have another F5 with 11.5.3 and the same application in place. Important aspects: HTTPS-VS, simple clientssl and an irule clientssl profile -> Client Authentication: set to ignore, but the Trusted CA/Advertised CA are set to a bundle (XYZ) there's an irule that checks for the URI, if it is /admin, following is done: SSL::session invalidate SSL::authenticate always SSL::authenticate depth 9 SSL::cert mode require SSL::renegotiate enable SSL::renegotiate there are two different types of client certificates: with SHA1 and with SHA256. cipher string on both F5s is: DEFAULT:-TLSv1_1:-TLSv1:-SSLv3:-SSLv2:-RC4:-DES:-3DES So the VS doesn't require a client-certificate by default, except for /admin. If /admin is requested, a SSL-renegotiation takes place. The client certificate is now "required", checked against XYZ bundle, and additionally checked against a data group of serial numbers. Now the issue: with v11.5.3 it worked properly for all certificates/browsers, and still works on the test-F5 since the update to v12.1.2 HF2, the SHA-1 certificates don't work any more, but SHA-256 do with IE11 it works when disabling sslv2/v3 in the options with IE11 it doesn't work with SHA1 when enabling sslv2/v3 in the options in IE11 in both cases the same Cipher Suite is used in any of the cases the client is asked to choose the certificate and enter the PIN (so the renegotiate part works) Following error occurs in LTM log: Connection error: ssl_shim_vfycerterr:4539: application verification failure (46) Does anyone have an idea where or what to check? At first I assumed different Cipher settings that have effect, because the default ciphers are different between v11/v12. But when I adapted the string to match exactly, it still didn't work. Now I assume that some other default settings in the SSL-profile or the handling of the SHA-1 certificates may have changed in some way. But the strange thing is this behavior of IE11 with sslv2/sslv3 - normally it should only change the supported ciphers of the client/browser. But in both cases the same one is used and still works. I also thought, maybe it is a browser issue (Chrome / SHA-1 support) - but since it works fine when connecting to an v11 F5, that shouldn't be the case. Thanks in advance!
SSL Client Auth fails after first wrong Issuer - doesnt test following Issuers
Hi, i have a problem with client certificate authentication. I think i found the problem, but still miss the answer. The situation is, there is a semi-public Trustcenter and i need to allow only clients with a valid client certificate. So i bundled all the Root and Intermediate Certificates into a chain file. But tests showed only ssl handshake failures : Dec 9 10:25:23 f5-111 info tmm1[15991]: 01260013:6: SSL Handshake failed for TCP 10.40.1.83:40652 -> 10.30.1.213:443 Dec 9 10:25:24 f5-111 debug tmm1[15991]: 01260006:7: Peer cert verify error: ok (depth 1; cert /C=DE/O=ITSG TrustCenter fuer Arbeitgeber) Dec 9 10:25:24 f5-111 debug tmm1[15991]: 01260006:7: Peer cert verify error: ok (depth 1; cert /C=DE/O=ITSG TrustCenter fuer Arbeitgeber) Dec 9 10:25:24 f5-111 debug tmm1[15991]: 01260006:7: Peer cert verify error: certificate signature failure (depth 0; cert /C=DE/O=ITSG TrustCenter fuer Arbeitgeber/OU=Deutsche Rentenversicherung Bund/OU=BN66667777/CN=Tino Pfeil) Dec 9 10:25:24 f5-111 debug tmm1[15991]: 01260009:7: Connection error: ssl_shim_vfycerterr:4249: certificate signature failure (42) Dec 9 10:25:24 f5-111 info tmm1[15991]: 01260013:6: SSL Handshake failed for TCP 10.40.1.83:34058 -> 10.30.1.213:443 I tried it with openssl verify and got this error: error 7 at 0 depth lookup:certificate signature failure 46953852812416:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:102: 46953852812416:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:944: 46953852812416:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:233: The problem is, i think, that there are 3 root certificates and multiple intermediate certs with the same name and hash but different serials. If i change order, so that the real issuer of the client is the first certificate, openssl verify gives "ok". When i put another intermediate with the same hash before the real issuer in the file, i get this error. So it seems verify process fails because openssl checks the digital signature of the first matching issuer (by issuer_hash), and if it fails the process stops without checking if there might be another issuer with a valid digital signature.. So how can i let the F5 check if any of the included intermediate certs is a valid one, and don't let the process fail after the first wrong. I found a KB which could be the right one for my problem, but i need a downtime to update, currently installed 11.6.0 HF8.
VIP with SSL certs and Simple URL Append iRule Help
Hi, Wondering if anyone could help me, I'm a beginner when it comes to TCL scripting so I'm hoping someone could shed some light with appending a link to an SSL URL using an iRule. My issue... VIP configured with SSL profile with both client and server-side encryption profiles (its company security policy requirement that client to F5 and F5 to web server communication be encrypted) np, works 100%, however, I need users who connect to (VIP) https://website.testdomain.com/ to be forwarded to https://website.testdomain.com/users/signon.html I've created an iRule and added it to the SSL VIP using the following, however, it still does not append the URL, what am I missing? when HTTP_REQUEST { if { [HTTP::path] equals "/" } { HTTP::redirect "/users/signon.html" } } Thanks in advance!
Trouble with Smart Card Login to the F5 Web Management UI
I've read https://devcentral.f5.com/questions/smart-card-login-to-f5-web-management and https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-user-account-administration-12-0-0/6.html but I'm having trouble getting smart cards to work to login to the web management console of the F5 itself. We are a Active Directory shop (2012), and if we need to tweak our Smart Card certs for this, we can. I can get the management site to verify the client cert, but no authentication happens--you just land at the login page (where you can enter name/password, and it successfully authenticates, but that defeats the purpose). I've uploaded our internal root CA certificate to the Apache Certificates store, and configured httpd as follows (note: the GUI for cert-LDAP piece ALWAYS turns on OCSP checking, regardless of the setting--this is really annoying): sys httpd { auth-pam-idle-timeout 1800 log-level debug ssl-ca-cert-file /Common/InternaCA-cert ssl-ciphersuite DEFAULT:!3DES:!LOW:!MD5:!EXPORT ssl-verify-client require ssl-verify-depth 20 } And then have tried several variations on the following (the subject of our Smart Card certs is the DistinguishedName, and we have the userPrincipalName in the subject alternate name-these accounts don't have email addresses). The accounts/domains are sanitized in the code below: auth cert-ldap system-auth { bind-dn "CN=LDAP Runner,OU=Other,OU=Users-Internal,DC=contoso,DC=com" bind-pw BINDPASSWORD check-roles-group enabled debug enabled login-attribute sAMAccountName login-name userPrincipalName search-base-dn OU=Users-Internal,DC=Contoso,DC=com servers { dc8.contoso.com } ssl-cname-field san-other ssl-cname-otheroid 1.3.6.1.4.1.311.20.2.3 sso on } I've tried combinations of the CN and OID for the UPN. Watching the tcpdump traffic, I can see that there's no LDAP traffic at all (unless you enter the user name and password in the forms). The httpd logs aren't showing anything that seems useful, though lots and lots of: Sep 23 18:04:30 F502EU err httpd[21790]: [error] [client 127.0.0.1] AUTHCACHE PAM: user 'admin' - not authenticated: Authentication failure Which corresponsds to lots and lots of: Sep 23 19:10:19 F502EU err httpd[22289]: [error] [client 127.0.0.1] AUTHCACHE PAM: user 'admin' - not authenticated: Authentication failure Sep 23 19:10:19 F502EU info httpd(pam_audit)[22289]: User=admin tty=(unknown) host=127.0.0.1 failed to login after 1 attempts (start="Fri Sep 23 19:10:17 2016" end="Fri Sep 23 19:10:19 2016"). What am I missing?
Passthrough Clientcertificate from Client -> F5 -> Back-End-Server
Hello, we've configured a Virtual Server with an attached HTTPS client and HTTPS server profile. We would like to use Client Certificate Authentication between the User (Client) and our Back-End-Server (Node). The problem is, that the SSL connection terminates on the F5 System. So we are not able to pass through the SSL Client Certificate Information to Back-End-Server (Node) Also the validity of the Client-Certificate should be checked on the F5. The CA-Certificate of the Client-Certificate should be placed on the F5 and only these Client-Certificates should be able to call the node. It should be possible to allow more than one ROOT-Certificate. The SSL-Proxy Mode is no option for us, because we can only use weak ciphers when the Mode is active. Is there a way to pass through the SSL Client Certificate to Back-End-Server? Maybe with an iRule? Kind Regards Winnie
Multiple Client Certificates - Query using single Virtual Server SSL Profile (Client)
I have an interesting one, and just started digging into its creation. I need to perform an OCSP check (easy), collect information off of 1 of 3 certificates a client might have on their token (easy), and pass that information on to the webserver (got that one all day long). Now for the curve ball. At somepoint in the APM policy, I have to query 1 of the other 2 certificates for another piece of information (think an email certificate vs. one used for authentication), but I can't mess with the data (or session) from the original certificate. My first few tries forces the session to reset and I lost the session data collected on the initial query. Thoughts?? open to ideas.. One knowledge nugget, I have to use the same URL, maintain the current session, and pass the data from both certs (that are in the same chain, covered by the same cert bundle) on to the web/app server. I might be able to use different URIs, so not sure if that helps.. ThanksPreserve client IP and client certificate with SharePoint
Using x-forwarded-for preserves the client IP but interferes with Common Access Card (CAC) authentication when using AUTOmap with a Standard vs. We have switched to nPath routing for generic application servers to preserve both client IP and client certificate. How or can we preserve both the source IP and client certificate for a Sharepoint application server (2010 and 2016)? Unfortunately an inline configuration is out of the question. Look forward to suggestions or recommended reading. Sharepoint: Client (ip, CAC) <--> LTM/VIP/pool <--> Real Servers (CAC authentication) nPath: Client (ip, CAC) --> LTM/VIP/pool --> Real Servers (ip, CAC authentication) data returns to client via router
Client Certificate Authentication - Exchange 2016 iApp
I have the Exchange 2016 iApp setup and working. I want to configure client certificate authentication for OWA/ECP/ActiveSync, and possibly OA in the future. Has anyone successfully accomplished this within the iApp, or do I need to consider doing a generic SSL passthrough profile of some kind?Proxy SSL and ECC ciphers
So I know that currently Proxy SSL does not support anything other than RSA key exchanges. I don't know if anyone had found any other way to do certificate authentication on the web server while still maintaining ASM inspection. I have an application where we have been restricting it down to RSA key exchanges only in order to use Proxy SSL so that the client cert could still pass to the web server but we could keep ASM inspection of the content. Now we have an issue where we need to turn on ECC ciphers, which will break Proxy SSL inspection and possibly force us to completely bypass ASM inspection. I would prefer not to bypass ASM but not seeing a way around it right now. Any help would be appreciated. Thanks.