Thank you for the information. The Root CA did indeed have a CRL. I added that to my combined CRL, in the order local CRL, external root CRL, external intermediate CRL and everything worked.
Thanks again, Mike -----Original Message----- From: Toft Alex (HEALTH AND SOCIAL CARE INFORMATION CENTRE) [mailto:[email protected]] Sent: Saturday, November 07, 2015 11:51 AM To: [email protected] Subject: EXTERNAL: Re: HAProxy with multiple CRL's That error message is somewhat unhelpful, as a colleague discovered recently. HAProxy will check the chain right the way up, so CA>Cert needs handling differently to CA>IntermediateCA>Cert which is generally what you'll get from a commercial CA. In the latter situation the IntermediateCA will also have a CRL Distribution Point attribute and you need that CRL too (technically it's called an ARL and generated much less frequently). Root CA certs at the top of the chain should NOT have a CRLDP, but some people do make that mistake. "ssl_sock_bind_verifycbk" in ssl_sock.c is where the verification is performed by handing off to OpenSSL. Sure enough, the OpenSSL error code is there c/o "err = X509_STORE_CTX_get_error(x_store)" but is never logged or otherwise used outside this function; instead the somewhat more generic message you received is output. General premise is that every link in the CA chain is checked by OpenSSL; if the cert has a CRLDP it will try to verify it even for a badly configured root CA. If you want to get rid of ARL checking higher up the chain but retain normal CRL checking it's a very quick tweak. In ssl_sock.c, after these linesŠ /* check if CA error needs to be ignored */ if (depth > 0) { Add something like this: if (err == 3) { // Uncomment line below to output debug to stdout // printf("ARL could not be checked in the client CA chain at depth %d - activating hideously dirty hack :)\n",depth); ERR_clear_error(); return 1; } If the depth is greater than 0 you're verifying the revocation status of a CA certificate. If the error code is 3 it corresponds to X509_V_ERR_UNABLE_TO_GET_CRL as per the OpenSSL x509_vfy.h Alex T From: "Harvan, Michael P" <[email protected]> Date: Friday, 6 November 2015 at 21:03 To: "[email protected]" <[email protected]> Subject: HAProxy with multiple CRL's Hi. I would like to configure HAProxy to allow multiple CRL¹s. First, for testing I created my own CA. I created a server cert and signed it. I created a client cert and signed it. I created a CRL. I setup HAProxy like: bind *:443 ssl crt server.crt ca-file my_ca.crt crl-file my_ca.crl That worked fine. The ssl connection prompted me for a cert signed by the CA present in the ca.crt file. I could give it a valid cert, an expired cert and a revoked cert and they all worked as expected. Then I tried integrating with an external CA for which I have a valid client cert, the CA cert and the CA CRL. I concatenated the CA certs to a combined.crt file. Then I concatenated the CRL files to a combined.crl file even though I have read posts that say that invalidates the CRL. There are other posts that say that should work. My HAProxy config is now: bind *:443 ssl crt server.crt ca-file combined.crt crl-file combined.crl The interface will accept a client cert signed by my own CA. If I don¹t specify a CRL it will also accept a client cert signed by the external CA. But, if I specify the crl-file, it will not accept the client cert from the external CA. I tried using just the external CA cert and the external CRL: bind *:443 ssl crt server.crt ca-file external.crt crl-file external.crl That will not work either. The error in both cases is ³SSL client CA chain cannot be verified² But I only get that if I specify the crl-file. I Any help is appreciated! Thanks. Mike ******************************************************************************************************************** This message may contain confidential information. If you are not the intended recipient please inform the sender that you have received the message in error before deleting it. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Thank you for your co-operation. NHSmail is the secure email and directory service available for all NHS staff in England and Scotland NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients NHSmail provides an email address for your career in the NHS and can be accessed anywhere ********************************************************************************************************************
