openssl for self signed certificates
Hi , Since openssl.1.0.1c doesn't support ECDHE-ECDSA-AES128-CCM cipher suite, I added this support in the openssl code. It works fine with ECC certificates which are not self-signed. When I process my ECC self-signed certificate, my webserver throughing X5* 09_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE* error during certificate verification. Attached is the ECC self signed certificate with ECDHE-ECDSA-AES128-CCM cipher suite. Pls throw some light to understand this problem . Rgds Indra Certificate: Data: Version: 3 (0x2) Serial Number: 3423928322 (0xcc150002) Signature Algorithm: ecdsa-with-SHA256 Issuer: O=XXX Self-Signed Client, CN=SS-Client CC150002 Validity Not Before: Mar 3 19:32:05 2013 GMT Not After : Mar 3 19:32:05 2016 GMT Subject: O=XXX Self-Signed Client, CN=SS-Client CC150002 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:66:13:1c:ac:34:d0:74:dc:cd:59:96:25:62:09: 02:a9:65:09:af:6a:0a:74:5b:40:65:38:cc:cf:34: b0:47:93:9f:80:3d:93:66:66:a9:dd:f1:7f:db:d7: 5b:2a:c5:fe:4b:97:d9:d4:51:50:e1:86:d2:2a:1e: 36:2d:59:31:fd ASN1 OID: prime256v1 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Agreement X509v3 Certificate Policies: critical Policy: 1.3.6.1.4.1.40732.2.2 Signature Algorithm: ecdsa-with-SHA256 30:46:02:21:00:df:b0:69:a9:d7:70:ae:d6:a3:a1:09:98:a6: c4:74:57:62:4b:0c:89:37:3a:b6:18:0d:cf:99:1d:79:09:cc: db:02:21:00:d3:7f:e6:1c:d2:2c:55:47:7c:41:fb:05:bc:28: 12:b1:0c:3e:f4:ff:2a:cf:a5:ad:a5:4c:33:56:2c:d4:8d:26
Re: openssl for self signed certificates
On 31-07-2013 08:22, Indtiny s wrote: Hi , Since openssl.1.0.1c doesn't support ECDHE-ECDSA-AES128-CCM cipher suite, I added this support in the openssl code. It works fine with ECC certificates which are not self-signed. When I process my ECC self-signed certificate, my webserver throughing X5*/09_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE/*error during certificate verification. Attached is the ECC self signed certificate with ECDHE-ECDSA-AES128-CCM cipher suite. Pls throw some light to understand this problem . Well you have marked the certificate policy extension as critical, which means that validation must fail if the software doing the verification does not know that Smart Energy 2.2 policy and how to verify the certificate and its usage against its criteria. In contrast, not marking an extension as critical means that software is allowed to ignore it. So marking the well known key usage as critical ensures that any software too old to obey the restriction cannot use the certificate which is good. Marking your CPS as critical limits use of the certificate to software specially modified to recognize it. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OCSP and self signed
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
In Boolean logic, we have the following possibilities:
- Root is trusted, so the revocation is valid, so the root is not
trusted. This is a contradiction so cannot hold.
- Root is not trusted, by elimination this must be true.
You have to communicate this fact out-of-band.
I never understood why some root-cas put a crldp extension into their
own certs.
this has sense in any cert except the root (self-signed) cert.
It makes sense for any non-broken client implementation.
Ideally, such roots keep an off-line copy of a pre-signed self-
revocation CRL, similar to the procedure used by experienced PGP
users (those who actually read the PGP 2.x manual). In case of
combined key compromise and loss, the off-line CRL is published,
thereby revoking the entire hierarchy.
The worst case disaster scenario is a large scale armed attack on the
center that keeps the private key. The attackers now have exclusive
control of the private key. But a far away trusted person can still
retrieve the self-destruction CRL and publish it through every means
imaginable, such as S/MIME e-mails (PEM style), sending it to software
update organisations (Microsoft, Mozilla, Apple, Google...) and for
all but one country, getting IANA/Internic assistance to force repoint
the DNS names of the CRL server to another server that serves up this
CRL and a message about the compromise.
The less worst case disaster scenario is an ordinary key compromise,
where the CA still has the private key and can sign a more precisely
dated revocation CRL and put the OCSP server in all is revoked mode.
Unfortunately, OpenSSL is broken and will apparently ignore all such
emergency messages.
Jakob, I don't understand your reasoning here.
You can't trust a signature of a compromised key. So if the root-ca's private
key gets compromised, you can't trust any of its issued crls and certificates
anymore. As such, pre-generating a crl for the case the root-ca doesn't have
access to its private key anymore doesn't seem to make sense. The root-ca's
only choice here is communicating this fact out of band to its customers, so
they can remove the compromised root-ca certificate from their truststores,
which is exactly what is happening today. The browser vendors even put it on an
internal blacklist, so re-adding it to the truststore won't have any effect. I
can't see where openssl is broken in this regard.
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
SSL error after machine restart.
Hi We are using openssl 0.9.8 in our application. Things are working fine and suddenly we are having . Linux awtah.dispatchserver1 3.6.11-1.fc16.i686 #1 SMP Mon Dec 17 21:36:23 UTC 2012 i686 i686 i386 GNU/Linux error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:426: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:288: error:1408F096:SSL routines:SSL3_GET_RECORD:encrypted length too long:s3_pkt.c:346: this error was random. Even though application uses it's own opnesssl 0.9.8 and M/C have 1.0.0j-fips. -bash-4.2# openssl version -a OpenSSL 1.0.0j-fips 10 May 2012 built on: Tue May 15 18:44:01 UTC 2012 platform: linux-elf options: bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM OPENSSLDIR: /etc/pki/tls engines: aesni dynamic On reinstalling 1.0.0j-fips on this Machine error got fixed. Now for the same application on Fedora 14, after reboot we have encountered the above problem. Linux 3UPCAWT605 2.6.35.6-45.fc14.i686 #1 SMP Mon Oct 18 23:56:17 UTC 2010 i686 i686 i386 GNU/Linux Any pointer what is the root cause of this problem or how to fix this. Open SSL installed on second M/C built on: Wed Sep 7 18:59:14 UTC 2011 platform: linux-elf options: bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM OPENSSLDIR: /etc/pki/tls engines: aesni dynamic Is there any configuration changes need to be done/service need to be restarted. With Regards Rajeev Tomar Team Automation Turning Possibilities Into Realites === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===
Re: SUIT-B supported cert/keys
anyone? -- View this message in context: http://openssl.6102.n7.nabble.com/SUIT-B-supported-cert-keys-tp45753p46006.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OCSP and self signed
On 31-07-2013 11:02, Eisenacher, Patrick wrote: -Original Message- From: Jakob Bohm On 30-07-2013 20:53, Walter H. wrote: On 30.07.2013 19:51, Eisenacher, Patrick wrote: In Boolean logic, we have the following possibilities: - Root is trusted, so the revocation is valid, so the root is not trusted. This is a contradiction so cannot hold. - Root is not trusted, by elimination this must be true. You have to communicate this fact out-of-band. I never understood why some root-cas put a crldp extension into their own certs. this has sense in any cert except the root (self-signed) cert. It makes sense for any non-broken client implementation. Ideally, such roots keep an off-line copy of a pre-signed self- revocation CRL, similar to the procedure used by experienced PGP users (those who actually read the PGP 2.x manual). In case of combined key compromise and loss, the off-line CRL is published, thereby revoking the entire hierarchy. The worst case disaster scenario is a large scale armed attack on the center that keeps the private key. The attackers now have exclusive control of the private key. But a far away trusted person can still retrieve the self-destruction CRL and publish it through every means imaginable, such as S/MIME e-mails (PEM style), sending it to software update organisations (Microsoft, Mozilla, Apple, Google...) and for all but one country, getting IANA/Internic assistance to force repoint the DNS names of the CRL server to another server that serves up this CRL and a message about the compromise. The less worst case disaster scenario is an ordinary key compromise, where the CA still has the private key and can sign a more precisely dated revocation CRL and put the OCSP server in all is revoked mode. Unfortunately, OpenSSL is broken and will apparently ignore all such emergency messages. Jakob, I don't understand your reasoning here. You can't trust a signature of a compromised key. So if the root-ca's private key gets compromised, you can't trust any of its issued crls and certificates anymore. This is where your and OpenSSL's logic fails: If you receive a signed message from a CA saying it cannot be trusted, you have 3 ways to react: A) Just believe it and revoke the CA. B) Assume it cannot have been legitimately generated and must thus have been created by means of a compromised key, thus concluding that the CA can no longer be trusted. C) Ignore it and proceed as if you have not seen it, which is very, very stupid. Because A and B have the same effect and require the same code, they are equally good. C is just plain crazy. As such, pre-generating a crl for the case the root-ca doesn't have access to its private key anymore doesn't seem to make sense. The root-ca's only choice here is communicating this fact out of band to its customers, so they can remove the compromised root-ca certificate from their truststores, which is exactly what is happening today. The browser vendors even put it on an internal blacklist, so re-adding it to the truststore won't have any effect. I can't see where openssl is broken in this regard. All the recent out of band root revocations have involved revocation against the will of a no longer trustworthy CA. So the CA was not communicating remove our root, and the trust store distributors had to act out of band and take countermeasures in case the bad CA persisted in socially engineering people to add them back in local trust stores. My complaint is about situations where CA officials willingly revoke one of their roots. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL error after machine restart.
On 31-07-2013 11:16, Rajeev Tomar wrote: Hi We are using openssl 0.9.8 in our application. Things are working fine and suddenly we are having . Linux awtah.dispatchserver1 3.6.11-1.fc16.i686 #1 SMP Mon Dec 17 21:36:23 UTC 2012 i686 i686 i386 GNU/Linux error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:426: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:288: error:1408F096:SSL routines:SSL3_GET_RECORD:encrypted length too long:s3_pkt.c:346: this error was random. Even though application uses it’s own opnesssl 0.9.8 and M/C have 1.0.0j-fips. Two things to check: - Use the command cut -c 50- /proc/pid/maps | uniq (Change 50 to 74 on 64-bit kernels) to make sure your application is not loading a dynamic libcrypt or libssl anyway. - If your application uses the shared certificate trust store in /etc/ssl/certs, note that OpenSSL 1 and OpenSSL 0.9 use incompatible formats for the symlinks in that directory, so either you need to use a different directory for your OpenSSL 0.9 applications or you need some special tricks to set up a combined directory. -bash-4.2# openssl version -a OpenSSL 1.0.0j-fips 10 May 2012 built on: Tue May 15 18:44:01 UTC 2012 platform: linux-elf options: bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM OPENSSLDIR: /etc/pki/tls engines: aesni dynamic On reinstalling 1.0.0j-fips on this Machine error got fixed. Now for the same application on Fedora 14, after reboot we have encountered the above problem. Linux 3UPCAWT605 2.6.35.6-45.fc14.i686 #1 SMP Mon Oct 18 23:56:17 UTC 2010 i686 i686 i386 GNU/Linux Any pointer what is the root cause of this problem or how to fix this. Open SSL installed on second M/C built on: Wed Sep 7 18:59:14 UTC 2011 platform: linux-elf options: bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM OPENSSLDIR: /etc/pki/tls engines: aesni dynamic Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OCSP and self signed
-Original Message- From: Jakob Bohm On 31-07-2013 11:02, Eisenacher, Patrick wrote: -Original Message- From: Jakob Bohm On 30-07-2013 20:53, Walter H. wrote: On 30.07.2013 19:51, Eisenacher, Patrick wrote: Jakob, I don't understand your reasoning here. You can't trust a signature of a compromised key. So if the root-ca's private key gets compromised, you can't trust any of its issued crls and certificates anymore. This is where your and OpenSSL's logic fails: If you receive a signed message from a CA saying it cannot be trusted, you have 3 ways to react: A) Just believe it and revoke the CA. B) Assume it cannot have been legitimately generated and must thus have been created by means of a compromised key, thus concluding that the CA can no longer be trusted. C) Ignore it and proceed as if you have not seen it, which is very, very stupid. Because A and B have the same effect and require the same code, they are equally good. C is just plain crazy. As such, pre-generating a crl for the case the root-ca doesn't have access to its private key anymore doesn't seem to make sense. The root-ca's only choice here is communicating this fact out of band to its customers, so they can remove the compromised root-ca certificate from their truststores, which is exactly what is happening today. The browser vendors even put it on an internal blacklist, so re-adding it to the truststore won't have any effect. I can't see where openssl is broken in this regard. All the recent out of band root revocations have involved revocation against the will of a no longer trustworthy CA. So the CA was not communicating remove our root, and the trust store distributors had to act out of band and take countermeasures in case the bad CA persisted in socially engineering people to add them back in local trust stores. My complaint is about situations where CA officials willingly revoke one of their roots. As I said before, there's no pki-inherent mechanism to revoke a self signed certificate other than to remove it from your truststore. This is the inverse step to giving the certificate trust by adding it to the truststore earlier. The root-ca needs to communicate this fact out of band to its customers, whether it wants to willingly withdraw the certificate or whether it was hacked and is forced to withdraw it doesn't matter here. This communication can be via phone call/snail mail/website announcement/signed mail by a still trusted certificate, i.e. belonging to a different pki/unsigned mail/whatever is stated in the ca's cps. Alternatively, the media can jump in and spread the news. In any case, such a situation always involves action on your side to adjust your trust settings, as there is no pki-automatism that can help you. Patrick Eisenacher
Re: openssl for self signed certificates
Hi , If there are no v3 extensions in the certificate, verify goes fine , If I add keyUsage , I get the below error . *X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE* But as per standard which I have follow for certficate generation , I have to create the certificate with these extensions . is there any way to disable that check using some ctx flag or do I need to comment check in the code ..? Rgds Indra
how to do SSL_shutdown()
Hi All, I am using openssl-1.0.1c in our project.when SSL_shutdown(ssl) get executed it returns 0.If I get return value zero then calling the same SSL_shutdown(ssl) again.In 2nd time it return -1. Can any one tell me how to shutdown ssl context ? How can I execute SSL_shutdown(ssl) , so that it will return 0 . Thanks Priyaranjan
Re: OCSP and self signed
Eisenacher, Patrick wrote: -Original Message- From: Jakob Bohm On 31-07-2013 11:02, Eisenacher, Patrick wrote: -Original Message- From: Jakob Bohm On 30-07-2013 20:53, Walter H. wrote: On 30.07.2013 19:51, Eisenacher, Patrick wrote: Jakob, I don't understand your reasoning here. You can't trust a signature of a compromised key. So if the root-ca's private key gets compromised, you can't trust any of its issued crls and certificates anymore. This is where your and OpenSSL's logic fails: If you receive a signed message from a CA saying it cannot be trusted, you have 3 ways to react: A) Just believe it and revoke the CA. B) Assume it cannot have been legitimately generated and must thus have been created by means of a compromised key, thus concluding that the CA can no longer be trusted. C) Ignore it and proceed as if you have not seen it, which is very, very stupid. Because A and B have the same effect and require the same code, they are equally good. C is just plain crazy. As such, pre-generating a crl for the case the root-ca doesn't have access to its private key anymore doesn't seem to make sense. The root-ca's only choice here is communicating this fact out of band to its customers, so they can remove the compromised root-ca certificate from their truststores, which is exactly what is happening today. The browser vendors even put it on an internal blacklist, so re-adding it to the truststore won't have any effect. I can't see where openssl is broken in this regard. All the recent out of band root revocations have involved revocation against the will of a no longer trustworthy CA. So the CA was not communicating remove our root, and the trust store distributors had to act out of band and take countermeasures in case the bad CA persisted in socially engineering people to add them back in local trust stores. My complaint is about situations where CA officials willingly revoke one of their roots. As I said before, there's no pki-inherent mechanism to revoke a self signed certificate other than to remove it from your truststore. not really; a CA that has to revoke one of their root cert. - these are always self signed - uses a cert that comes from another root cert., or this root cert itself to sign the CRL where it revokes the compromised root cert; doing so has a total different quality: the CA can't remove their compromised root cert from the trusted cert store of your system, but with the CRL they can tell your system, not to trust any cert that was signed by the compromised root cert; for signing a CRL there is no restriction about the content; but for OCSP there exists a restriction: the cert used for signing the OCSP responders must have been signed by the same CA cert as the certs itself; there exists a very strange situation when the CA cert has expired, because there is no CA cert available that can sign the OCSP responder certificate; the only cert that can't be checked by OCSP is the root cert itself; you would do a good job that your CA cert signs only certs, that will expire before the CA cert itself will expire ... Greetings, Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: OCSP and self signed
On 31-07-2013 16:01, Walter H. wrote: Eisenacher, Patrick wrote: -Original Message- From: Jakob Bohm On 31-07-2013 11:02, Eisenacher, Patrick wrote: -Original Message- From: Jakob Bohm On 30-07-2013 20:53, Walter H. wrote: On 30.07.2013 19:51, Eisenacher, Patrick wrote: Jakob, I don't understand your reasoning here. You can't trust a signature of a compromised key. So if the root-ca's private key gets compromised, you can't trust any of its issued crls and certificates anymore. This is where your and OpenSSL's logic fails: If you receive a signed message from a CA saying it cannot be trusted, you have 3 ways to react: A) Just believe it and revoke the CA. B) Assume it cannot have been legitimately generated and must thus have been created by means of a compromised key, thus concluding that the CA can no longer be trusted. C) Ignore it and proceed as if you have not seen it, which is very, very stupid. Because A and B have the same effect and require the same code, they are equally good. C is just plain crazy. As such, pre-generating a crl for the case the root-ca doesn't have access to its private key anymore doesn't seem to make sense. The root-ca's only choice here is communicating this fact out of band to its customers, so they can remove the compromised root-ca certificate from their truststores, which is exactly what is happening today. The browser vendors even put it on an internal blacklist, so re-adding it to the truststore won't have any effect. I can't see where openssl is broken in this regard. All the recent out of band root revocations have involved revocation against the will of a no longer trustworthy CA. So the CA was not communicating remove our root, and the trust store distributors had to act out of band and take countermeasures in case the bad CA persisted in socially engineering people to add them back in local trust stores. My complaint is about situations where CA officials willingly revoke one of their roots. As I said before, there's no pki-inherent mechanism to revoke a self signed certificate other than to remove it from your truststore. not really; a CA that has to revoke one of their root cert. - these are always self signed - uses a cert that comes from another root cert., or this root cert itself to sign the CRL where it revokes the compromised root cert; As revoking the root indirectly revokes the child certs, and there is a security requirement that no out-of-hierarchy revocations are valid, it should not matter if the revocation is done by the root or one of its children. doing so has a total different quality: the CA can't remove their compromised root cert from the trusted cert store of your system, but with the CRL they can tell your system, not to trust any cert that was signed by the compromised root cert; Yes, and because they cannot know what certificates are falsely issued by the compromised key, a root-compromise CRL must list the root cert itself and need not list any other cert. for signing a CRL there is no restriction about the content; but for OCSP there exists a restriction: the cert used for signing the OCSP responders must have been signed by the same CA cert as the certs itself; Any correct implementation enforces a similar rule for CRLs, or cross-revocation mayhem may ensue. there exists a very strange situation when the CA cert has expired, because there is no CA cert available that can sign the OCSP responder certificate; If any CA in the chain is expired, revoked, or otherwise untrusted, there is no trust to check and no need for the OCSP responder to remain active (beyond a short transition for clients with bad clocks). the only cert that can't be checked by OCSP is the root cert itself; This is where I disagree, can you point me to an actual reason why not, which is not refuted by my logical ABC argument above. you would do a good job that your CA cert signs only certs, that will expire before the CA cert itself will expire ... Validity beyond the issuer is null and void due to clients checking all the expiry dates. Furthermore clients are allowed to reject certificates with non-nested validity even during the period where the validity overlaps. So on this point we agree. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OCSP and self signed
On 31.07.2013 16:47, Jakob Bohm wrote: the only cert that can't be checked by OCSP is the root cert itself; This is where I disagree, can you point me to an actual reason why not, which is not refuted by my logical ABC argument above. the Authority Information Access extension does not make any sense in root - self-signed - certs; keep in mind: Google changes (or has already changed) the root cert. on their servers and this will not be noticed by any user in the world, because the Google Internet Authority is issued by another CA that has its root in the trusted cert store of (nearly) every system in the world; Greetings, Walter smime.p7s Description: S/MIME Cryptographic Signature
RE: OCSP and self signed
-Original Message-
From: Walter H.
Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
As I said before, there's no pki-inherent mechanism to revoke a self signed
certificate other than to remove it from your truststore.
not really; a CA that has to revoke one of their root cert. - these are
always self signed - uses a cert that comes from another root cert., or
this root cert itself to sign the CRL where it revokes the compromised
root cert;
doing so has a total different quality: the CA can't remove their
compromised root cert from the trusted cert store of your system, but
with the CRL they can tell your system, not to trust any cert that was
signed by the compromised root cert;
This is not possible according to PKIX. RFC5280 states The trust anchor for
the certification path [of the crl] MUST be the same as the trust anchor used
to validate the target certificate.
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: OCSP and self signed
This is not possible according to PKIX. RFC5280 states The trust anchor for the certification path [of the crl] MUST be the same as the trust anchor used to validate the target certificate. The root certificate creates a crl-signing cert. The root certificate includes a cRLDistributionPoint that names that crl-signing cert, and has cACompromise in its ReasonFlags. The crl-signing cert immediately issues an empty CRL. Whenever you give someone the CA cert, you give them the crl cert, and the empty CRL as well. The relying party now has the key that will sign the CRL, and a signed piece of data using that key. This is more theory than practice -- how many angels can dance on the head of a pin? -- but it does securely give you a way to be sure that you only trust a proper root revocation. Whether or not that is something to do (as opposed to playing it safe and not worry about whether or not someone has compromised the root to sign its own CRL death warrant) is for others to argue. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: OCSP and self signed
On 31-07-2013 19:56, Salz, Rich wrote: This is not possible according to PKIX. RFC5280 states The trust anchor for the certification path [of the crl] MUST be the same as the trust anchor used to validate the target certificate. The root certificate creates a crl-signing cert. The root certificate includes a cRLDistributionPoint that names that crl-signing cert, and has cACompromise in its ReasonFlags. Wouldn't it be just as good to have a cRLDistributionPoint which does not restrict the available ReasonFlags and then put cACompromise in the CRL if/when that disaster happens? Wouldn't it be equally good to use the same crl-signing cert already used for the regular CRL of revoked next-level certs? Would it be possible to use the same CRL and cRLDistributionPoint for both child certs and self-revocation (abdication)? Would it be possible to use the above techniques without a separate crl-signing cert? The crl-signing cert immediately issues an empty CRL. Whenever you give someone the CA cert, you give them the crl cert, and the empty CRL as well. The relying party now has the key that will sign the CRL, and a signed piece of data using that key. This is more theory than practice -- how many angels can dance on the head of a pin? -- but it does securely give you a way to be sure that you only trust a proper root revocation. Whether or not that is something to do (as opposed to playing it safe and not worry about whether or not someone has compromised the root to sign its own CRL death warrant) is for others to argue. I prefer the term abdication, similar to what a king or other potentate can do. My idea is that by combining the simplifications above, the only extra infrastructure needed would be to have a cRLDistributionPoint in the root cert, same as in the child certs it issues. Then when clients download the CRL (to check a child cert), it may get the message that the whole hierarchy is now dead. Another use for such abdication CRLs is the Superseded scenario, such as revoking a 1024-bit root before its time, once all the intentionally issued child certs are no longer used and the new 2048-bit root has been fully deployed (by then the CA may already have published an 8192-bit root, given the current pace of things). Note about the risk of someone compromising a root to sign its abdication, the fact that someone has done so is itself proof that the root is now compromised, even if the legitimate root operator has not signed his own version of such a message. So as a client, the fact that an abdication has been signed by someone with access to the root key is proof enough regardless of the fact that this is then the last and only trust of the key. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OCSP and self signed
Wouldn't it be just as good to have a cRLDistributionPoint which does not restrict the available ReasonFlags and then put cACompromise in the CRL if/when that disaster happens? No because with my idea you are a priori restrict the crlDP to be only CA revocation. Wouldn't it be equally good to use the same crl-signing cert already used for the regular CRL of revoked next-level certs? Operational decision -- do you trust the people who revoke your certs exactly like you trust the people who revoke you ? Would it be possible to use the same CRL and cRLDistributionPoint for both child certs and self-revocation (abdication)? I think so, since they would be the same issuer and would have unique serial numbers. But in theory I'd want those jobs separate. I like the term abdication although it doesn't handle the regicide case; suppose others know the root is bad, but the king doesn't know it's dead :) But as I said, this is more about pedanticsm than practical real-world practice. (I used to work at a company that was perhaps the apotheosis of that) /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: OCSP and self signed
On 31-07-2013 22:11, Salz, Rich wrote: Wouldn't it be just as good to have a cRLDistributionPoint which does not restrict the available ReasonFlags and then put cACompromise in the CRL if/when that disaster happens? No because with my idea you are a priori restrict the crlDP to be only CA revocation. Wouldn't it be equally good to use the same crl-signing cert already used for the regular CRL of revoked next-level certs? Operational decision -- do you trust the people who revoke your certs exactly like you trust the people who revoke you ? The presumption is that I sign all the CRLs using a tool (a HSM) that will tell me if the underlings try to sneak in me on the list. Would it be possible to use the same CRL and cRLDistributionPoint for both child certs and self-revocation (abdication)? I think so, since they would be the same issuer and would have unique serial numbers. But in theory I'd want those jobs separate. The separation would be done at the CRL signing stage or before. Posting the abdication notice across the front page of the blacklist everybody is looking at improves efficiency. I like the term abdication although it doesn't handle the regicide case; suppose others know the root is bad, but the king doesn't know it's dead :) Like Saddam Hussein who still considered himself the president when they found him in his hidden personal bunker. But as I said, this is more about pedanticsm than practical real-world practice. (I used to work at a company that was perhaps the apotheosis of that) Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
