Hi
A cautious handling of heatbleed included renewing private keys and certificates. But that is of no interest if the possibly compromised certificate is not revoked, or if revokation is not enforced.
I therefore tried CRL in OpenLDAP (linked with OpenSSL). I first started with client settings, in ~/.ldaprc:
BASE dc=example,dc=net URI ldaps://ldap.example.net TLS_CACERT /etc/openssl/certs/ca.crt TLS_REQCERT demand TLS_CACERTDIR /home/manu/openssl/ca TLS_CRLCHECK all
As suggested in the man page, I added a copy of /etc/openssl/certs/ca.crt in /home/manu/openssl/ca and tried a ldapsearch on the server. It fails, and with debug output I have:
TLS certificate verification: Error, unable to get certificate CRL TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get certificate CRL). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
kernel trace show that before the error message, it attemps to open /home/manu/openssl/ca/0726b466.r0
If I rename the CA to that name, it will read it, then fail on:
TLS certificate verification: Error, unable to get certificate CRL TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:0906D06C:PEM routines:PEM_read_bio:no start line.
That suggests the man page is wrong and it is not expecting a CA there. If I remove the CA from /home/manu/openssl/ca/ and copy the CRL in /home/manu/openssl/ca/0726b466.r0, it reads it without a complain, then tries to read /home/manu/openssl/ca/0726b466.r1 and fail there.
If I copy /home/manu/openssl/ca/0726b466.r0 to /home/manu/openssl/ca/0726b466.r1, the message suggests that it is indeed trying to load the CRL from that file: TLS: can't connect: error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table.
I have a few questions before I start to read the code, just in case it is a known issue:
Why the cryptic file names? And why do I need a second 0726b466.r1 file? Using TLS_CRLCHECK peer instead of TLS_CRLCHECK all does not change the behavior.
And is OpenSSL CRL supposed to work? This is OpenLDAP 2.4.33
Hi,
On Sun, 13 Apr 2014, Emmanuel Dreyfus wrote: <snipp/>
it is standard openssl behavior to load certs from CERTHASH.0 and crls from CERTHASH.r0
You can generate the hash from a certificate using "openssl x509 hash"
ck@pohjola: {112} openssl x509 -noout -hash -in CA.cert faf58a99
You generally set a symlink from the hash to your certificate and crl using
ln -s CA.cert `openssl x509 -noout -hash -in CA.cert`.0 ln -s CA.crl `openssl x509 -noout -hash -in CA.cert`.r0
This logic is buried somewhere deep inside openssl and is activated when you configure the CA directory instead of explicit certs.
Greetings Christian
Christian Kratzer ck-lists@cksoft.de wrote:
it is standard openssl behavior to load certs from CERTHASH.0 and crls from CERTHASH.r0
I am glad it makses some sense. Is it documented anywhere?
I fixed the second like to be a link to the CRL and not to the CA.
It happily loads ${hash}.r0, it does not touch ${hash}.0, but it still looks for an inexistant ${hash}.r1 file. What should be there?
Hi,
On Sun, 13 Apr 2014, Emmanuel Dreyfus wrote:
propably somewhere in the openssl documentation. I have been setting up these symlinks for ages and can't remember where the reference is.
As you have explicitly configured you CA cert it does not need to look via hash.
It propably would when encountering a cert signed by a different CA than the one you configured but I am not that 100% on the actual logic.
looks for an inexistant ${hash}.r1 file. What should be there?
Propably an update to the crl. You would have to lookup the openssl docs to be sure.
Greetings Christian
Christian Kratzer ck-lists@cksoft.de wrote:
I think this is because the CRL Next Update is in the past. I will renew the CRL to check that.
Hi,
On Sun, 13 Apr 2014, Emmanuel Dreyfus wrote:
yes an expired crl will usually cause validation to fail.
I have experienced this regularly when forettting to update the crl for ipsec vpn with racoon. Should be the same for openldap.
Greetings Christian
On Sun, Apr 13, 2014 at 12:21:10PM +0200, Christian Kratzer wrote:
Now with a valid CRL, I still have the same problem: it loads /etc/openssl/certs/0726b466.r0, then tries and fails on: /etc/openssl/certs/0726b466.r1 /etc/openssl/cert.pem/0726b466.r0
And then it fails with this complain: TLS certificate verification: Error, unable to get certificate CRL
It considers that the CRL found at "hash".r0 isn't valid or sufficient to give a revocation status of your certificate. Could you post the subscriber certificate, its issuing CA cert, and the corresponding CRL somewhere?
2014-04-14 10:32 GMT+02:00 Emmanuel Dreyfus manu@netbsd.org:
Erwann Abalea eabalea@gmail.com wrote:
I found the problem: it was not signed by the right CA (same private key, different cert)
Now you've got another problem. Why do you have 2 different CAs with the same private key? It's getting more off-topic, sorry.
2014-04-14 20:23 GMT+02:00 Emmanuel Dreyfus manu@netbsd.org:
Erwann Abalea eabalea@gmail.com wrote:
Now you've got another problem. Why do you have 2 different CAs with the same private key?
First one is about to expire and second one will replace it. I do not recall why a new private key was not generated, but it is as is.
openldap-technical@openldap.org
-
Christian Kratzer -
Emmanuel Dreyfus -
Erwann Abalea -
Ferenc Wagner -
manu＠netbsd.org