9:09 p.m.
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
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
12:23 a.m.
Hi,
On Sun, 13 Apr 2014, Emmanuel Dreyfus wrote:
<snipp/>
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
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 Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
1:15 a.m.
Christian Kratzer <ck-lists(a)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?
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
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?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
1:14 a.m.
Hi,
On Sun, 13 Apr 2014, Emmanuel Dreyfus wrote:
Christian Kratzer <ck-lists(a)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?
propably somewhere in the openssl documentation. I have been setting
up these symlinks for ages and can't remember where the reference is.
> 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
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
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 Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
3:06 a.m.
Christian Kratzer <ck-lists(a)cksoft.de> wrote:
> 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.
I think this is because the CRL Next Update is in the past. I will
renew the CRL to check that.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
3:21 a.m.
Hi,
On Sun, 13 Apr 2014, Emmanuel Dreyfus wrote:
Christian Kratzer <ck-lists(a)cksoft.de> wrote:
>> 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.
I think this is because the CRL Next Update is in the past. I will
renew the CRL to check that.
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
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
1:32 a.m.
On Sun, Apr 13, 2014 at 12:21:10PM +0200, Christian Kratzer wrote:
>I think this is because the CRL Next Update is in the past. I
will
>renew the CRL to check that.
yes an expired crl will usually cause validation to fail.
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
--
Emmanuel Dreyfus
manu(a)netbsd.org
2:17 a.m.
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(a)netbsd.org>:
On Sun, Apr 13, 2014 at 12:21:10PM +0200, Christian Kratzer wrote:
> >I think this is because the CRL Next Update is in the past. I will
> >renew the CRL to check that.
>
> yes an expired crl will usually cause validation to fail.
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
--
Emmanuel Dreyfus
manu(a)netbsd.org
--
Erwann.
11:23 a.m.
Erwann Abalea <eabalea(a)gmail.com> wrote:
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?
I found the problem: it was not signed by the right CA (same private
key, different cert)
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
12:22 p.m.
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(a)netbsd.org>:
Erwann Abalea <eabalea(a)gmail.com> wrote:
> 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?
I found the problem: it was not signed by the right CA (same private
key, different cert)
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
--
Erwann.
5:05 p.m.
Erwann Abalea <eabalea(a)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.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
3:38 a.m.
manu(a)netbsd.org (Emmanuel Dreyfus) writes:
Christian Kratzer <ck-lists(a)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?
See man c_rehash, for example.
> 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
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?
Another cert or crl with the same hash. See the man page.
--
Regards,
Feri.
3334
days inactive
3336
days old
openldap-technical@openldap.org
11 comments
5 participants
participants (5)
-
Christian Kratzer -
Emmanuel Dreyfus -
Erwann Abalea -
Ferenc Wagner -
manu＠netbsd.org