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{,���
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: 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: 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
Re: OCSP and self signed
On 23-07-2013 23:56, Steven Madwin wrote: The short answers is no. An OCSP response has to be signed by the issuer (or a delegate of the issuer) and a self-signed cert is issued by itself. As a general rule certs can't revoke themselves so there is no need to get a revocation response for a self-signed cert. Once again, I would like to advocate that the openssl verification code should allow a self-signed certificate to revoke itself, using the same mechanisms as for revoking anything else. Specifically, for CA root certs: - A CA root can expire and/or fail other validity conditions just like everybody else. - If a CRL is available issued by the CA, the CA cert itself is (also) checked againstit. If a CRL declares its issuing CA invalid, no later CRL can counter this, regardlessof dates or signatures (because such a revocation is probably due to root key compromise,and any other CA signed message may be forged, while the possibility of a forged revocation is itself proof of compromise). - If an OCSP server is available, it is (also) asked about the root cert itself, and once asigned negative response is received, it overrides all other uses of that root. - In full systems (such as browsers), root-revocation messages (in CRL or OCSP form)should be stored permanently so no future (forged) response can undo them, the APIshould be designed so implementing this easy. Specifically for self-signed end entity certs: - Revocation checks should be done as for a CA root cert. - Where the protocols require/assume the CA cert to be marked with CA:TRUE, thisshould be ignored solely for the purpose of checking for self- revocation and self-issuance. 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
I agree with this Once again, I would like to advocate that the openssl verification code should allow a self-signed certificate to revoke itself, using the same mechanisms as for revoking anything else. I was wondering how the root cert gets revoked. Anyway thanks for posting that request. -- View this message in context: http://openssl.6102.n7.nabble.com/OCSP-and-self-signed-tp45918p45996.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
-Original Message- From: redpath I agree with this Once again, I would like to advocate that the openssl verification code should allow a self-signed certificate to revoke itself, using the same mechanisms as for revoking anything else. I was wondering how the root cert gets revoked. Anyway thanks for posting that request. A self-signed certificate can't be revoked via a crl, because you won't be able to successfully verify its signature. You have to communicate this fact out-of-band. I never understood why some root-cas put a crldp extension into their own certs. Patrick Eisenacher
Re: OCSP and self signed
On 30.07.2013 19:51, Eisenacher, Patrick wrote: I was wondering how the root cert gets revoked. Anyway thanks for posting that request. A self-signed certificate can't be revoked via a crl, because you won't be able to successfully verify its signature. keep in mind, that in case you detect a problem with your root certificate, you can revoke this cert, but have to use a different cert. for signing this CRL 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. Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: OCSP and self signed
On 30-07-2013 20:53, Walter H. wrote: On 30.07.2013 19:51, Eisenacher, Patrick wrote: I was wondering how the root cert gets revoked. Anyway thanks for posting that request. A self-signed certificate can't be revoked via a crl, because you won't be able to successfully verify its signature. keep in mind, that in case you detect a problem with your root certificate, you can revoke this cert, but have to use a different cert. for signing this CRL Only if you intentionally misread the specs! Any revocation of a cert (self-signed or not) has to trace back to the trusted self-signed cert. So revoking a self-signed cert (root or not) will always cancel out its own validity. Which is exactly the intended semantics of a root abdication. Now if an implementation misreads the specs to say that a root that has revoked itself should still be trusted, is fatally flawed in its logic. 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. 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
The short answers is no. An OCSP response has to be signed by the issuer (or a delegate of the issuer) and a self-signed cert is issued by itself. As a general rule certs can't revoke themselves so there is no need to get a revocation response for a self-signed cert. Steve -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of redpath Sent: Tuesday, July 23, 2013 10:27 AM To: openssl-users@openssl.org Subject: OCSP and self signed I was wondering about self signed certs. If I run the test OCSP it needs to know the CA cert but there is no CA cert. So can a OCSP responder work for self signed certs. -- View this message in context: http://openssl.6102.n7.nabble.com/OCSP-and-self-signed-tp45918.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 smime.p7s Description: S/MIME cryptographic signature
OCSP and self signed
I was wondering about self signed certs. If I run the test OCSP it needs to know the CA cert but there is no CA cert. So can a OCSP responder work for self signed certs. -- View this message in context: http://openssl.6102.n7.nabble.com/OCSP-and-self-signed-tp45918.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: problem with ocsp and self signed CA
Hi, any idea about I can trust self signed certificate, avoiding use of no chain verify flag? thanks, M.M. _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline
problem with ocsp and self signed CA
Dears,I'm in trouble with self signed certificate, when I try to verify via ocsp a certificate whose issuer is self signed.The error I receive is always openssl ocsp -issuer /usr/local/ssl/cert/issuerPEM.crt -cert ./certificatePEM.cer -url http://ocsp.foo.com -CApath /usr/local/ssl/certResponse Verify Failure1903:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:122:Verify error:self signed certificate in certificate chain Into /usr/local/ssl/cert I've copied the issuer certificate and created the ln -s hash link.Is that anyway to trust the self signed certificate? If I load the issuer certificate into IE browser,It appeares as root...Thanks in advanceMattew _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us
Re: problem with ocsp and self signed CA
On September 11, 2008 09:24:46 am matteo mattau wrote: Dears,I'm in trouble with self signed certificate, when I try to verify via ocsp a certificate whose issuer is self signed.The error I receive is always openssl ocsp -issuer /usr/local/ssl/cert/issuerPEM.crt -cert ./certificatePEM.cer -url http://ocsp.foo.com -CApath /usr/local/ssl/certResponse Verify Failure1903:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:122:Verify error:self signed certificate in certificate chain Into /usr/local/ssl/cert I've copied the issuer certificate and created the ln -s hash link.Is that anyway to trust the self signed certificate? If I load the issuer certificate into IE browser,It appeares as root...Thanks in advanceMattew Can you include the certificates involved in your problem report? Thanks. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: problem with ocsp and self signed CA
Can you include the certificates involved in your problem report? Thanks for reply attention, below the CA -BEGIN CERTIFICATE-MIIDwTCCAqmgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBgTELMAkGA1UEBhMCSVQxFzAVBgNVBAoTDkFjdGFsaXMgUy5wLkEuMSIwIAYDVQQLExlTZXJ2aXppIGRpIGNlcnRpZmljYXppb25lMTUwMwYDVQQDEyxBY3RhbGlzIENBIHBlciBBdXRlbnRpY2F6aW9uZSBDTlMgLSBDT0xMQVVETzAeFw0wNjAxMTAxNjI4NDdaFw0xNjAxMTExNjI4NDdaMIGBMQswCQYDVQQGEwJJVDEXMBUGA1UEChMOQWN0YWxpcyBTLnAuQS4xIjAgBgNVBAsTGVNlcnZpemkgZGkgY2VydGlmaWNhemlvbmUxNTAzBgNVBAMTLEFjdGFsaXMgQ0EgcGVyIEF1dGVudGljYXppb25lIENOUyAtIENPTExBVURPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxnRfL+rXC5oZUTIns4oA+HKGWLwe+Qp7c9zdXCA4E8dVkclP6GjUGgMGE0QVH8zrrbXr8ECiO9FW7h/pvHaeyDh7qvNYqMaJREFwsMxYozgcHwph4ddqkm480TJD3qS25+dkDdERU6d4UOjGjOud15pJ0Pv2wD6B2uz+e4voU0b/ovJ5eNYPHa3cP14nyuKfzZGfkaRUSj6Mz/cpAA8iY6Zi60exI0+KZyJYfZXoS44xHUB3EQfj37V7T3/8AwPuxiXHE27Q1MFop2GcSN4VeW/XrFZN+q37ie1VUIx92KNZTENKdOLDi8Z95w0/BrRAr/VtmiB2O1r92oVkkyNs1QIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUy6fQfHneB/OtrojpB/MmS8eyINEwDQYJKoZIhvcNAQEFBQADggEBAJRyBGGy+U4CWkTz1LRbClRPXg0jRlCnAxP3UXE1kTD2sUeDdsbd5unVZ4Q068M1VxkI6DT0M96pNTE4fF/TqBobGSTE0wTfYYVhW1DshoQXTkqCPVQEbx8dDy+RL+Vv3CKXH9rBsOdwOYiwk10od9PmgAx1RDpZsbQEVcMCHjggQTyqudsw00bxbNDoUbnG3jkcGOIHIgg0qzRXjHQSam9Ybt7TePeRDqIVG3kGcfqP852jWHuPBUwos1kFR5UhLqRqv1hfBUFe8TcHOBFKqmecnLa4wLZ1jrJVC29b6VbMhKRUkLLqCsI7oPG2CT1ernRxT3kitkqiTduTyaaYOQE=-END CERTIFICATE- _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline
