Tag Info

Hot answers tagged

20

The technical reason is to keep CRL size under control: CRL list the serial numbers of revoked certificates, but only for certificates which would otherwise be still valid, and in particular not expired. Without an end-of-validity period, revoked certificates would accumulate indefinitely, leading to huge CRL over time. However, since network bandwidth ...


11

There's just no way to fix it. Even if the registration period is two years and a one year certificate is issued, you could still sell or drop the registration next week. There's nothing the certificate authority can do about that. (Well, I suppose they could monitor the registrations and if there's a change in registrant, they could revoke the certificate. ...


10

There are several problems with OCSP. Some of them: It puts too strain on the OCSP responder (minor issue) It makes your browser respond slower, as it has to ask the CA before visiting the site. Privacy reasons: The CA gets the serial number requests for all the certificates you ask, so it can pinpoint which sites you visit. Who says it will not sell that ...


10

Although the certificate has a finite validity period it can be revoked at any time. The act of revocation places the serial number of that certificate into a certificate revocation list (CRL). Each certificate will include a link to a location where the latest CRL has been published by the issuer of that certificate. This means that if a certificate is no ...


8

It is a bug of OpenSSL (at least in version 1.0.1c); precisely, a bug of the command-line "ca" option handling. If you look at the apps/ca.c source file in OpenSSL source code, you may see that the MAIN() function begins by parsing the command-line options, then reads the configuration file, then does this: ...


7

Do I have any assurance that the previous owner does not have a valid HTTPS certificate for the site? No, you don't. CAs can issue certificate that are valid after the expiry date of the domain (at the time of issuance). Even if they didn't, a domain could be transferred before its expiry date. In addition, you can't possibly control all the CAs ...


7

Segmenting the space of certificates so that "partial" CRL can be computed is possible and supported, but it must be done properly. One base principle of CRL is that a CRL should be amenable to processing regardless of how it was obtained: that's the whole point of having signed objects. Since a certificate is considered as non-revoked by virtue of not ...


7

Some CA do not offer an OCSP server, relying instead on CRL (notably, full OCSP with support for client nonces is rather expensive for the CA). And among those who do implement OCSP, many botch the job, resulting in OCSP responses which are not, per se, verifiable (e.g. the OCSP response is signed with a dedicated OCSP responder certificate for which the ...


6

A couple fundamental things: The basis of a CRL is a promise for a certain time period. That means a begin time and an end time. Once a CRL is made and signed, it can't be changed, so it lasts as long as it lasts, and can't be trusted after that. In essence, you won't know until you check. A CRL in its regular form is one big list. You can't assume ...


6

The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points: Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used ...


5

The big one - IMO - is the speed. I've used a couple different plugs and configurations to enable OCSP in browsers, and even in a lab environment where the OCSP server is unburdened and one hop away in a high bandwidth environment, the OCSP checking can be a serious delay in session establishment. I've even gotten plenty of user complaints, even when the ...


5

I find the question useful, because it is actually hard to find out if a certificate got revoked the right way. If you know who issued the original certificate you can download the CRLs (which contains only the serial numbers and the date of revocation, not the revoked certificate itself). If not you are out of luck. If you know the serial number of the ...


5

There is no global directory of all issued certificates (X.509 was designed to support the Directory, but it never existed in practice). You will have to contact "all CA" and ask them nicely. Basically, this would mean going to their site, and using the "I lost my password" feature so as to regain control of your account, if it exists. Details vary depending ...


5

From RFC 5280 3.3 Revocation An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. If you have a lot of changes (people leaving etc.) it's best to not make the certificate validity too long otherwise the CRL can grow large (some CRLs are > 30MB which ...


4

EKU is Extended Key Usage; this is a certificate extension described in X.509 (RFC 5280), section 4.2.1.12. As the RFC says: In general, this extension will appear only in end entity certificates. because, contrary to "Certificate Policies", there is no notion of inheritance and propagation of EKU along a certificate path. The EKU extension tells ...


4

"Rekey" is a term which is usually employed when obtaining a new certificate: it means that you want the new certificate to use a newly generated key pair, instead of reusing the same public key as was in a previous certificate. "Revocation" is the act of declaring, on the CA side, that a given certificate should no longer be considered as valid (it is a ...


4

In practice, what software can support is uniformResourceIdentifier. The extension then contains a URI which points to the CRL. http:// and ldap:// URL are rather common; https:// URL for CRL download raise interesting issues since the server certificate must then also be validated (so, in practice, it does not work well, or at all). In situations where ...


4

A CA must indeed publish CRL regularly, and if the CA is offline, then human intervention is needed. Each CRL has an issuance date (thisUpdate) and a provisional date of next publication (nextUpdate) which everybody uses as an end-of-validity date for the CRL. The next CRL must be published before reaching the nextUpdate date of the current CRL; otherwise, ...


4

The first problem I can see is how do you find the first certificate? If you've visited the site before, then I suppose you could, but for anyone that doesn't keep certificates around from all the sites they have visited, we'd need some infrastructure to be able to look up all certificates that resolve for a particular CN. Additionally, such a system might ...


4

The private key of the CA is needed because the revocation must be signed by the CA. Else it would be possible that the revocation is done by any entity.


4

A CRL is a signed object, just like a certificate. This is why they need not be covered by the actual document signature. However, for long-term archival, they need to be timestamped. The theoretical background is the following: At a given time T, you may validate certificates and verify signatures by using just-downloaded CRL, which give guarantee about ...


4

You are using the expression "zero-knowledge proof" but it does not mean what you believe it to mean. A ZKP proof is a kind of cryptographic protocol by which a Prover demonstrates to a Verifier a given property on a secret value. The proof is "zero-knowledge" if it does not divulge any extra information to the verifier. For instance, suppose that there is ...


4

Partly solving the underlying problem, you may use Public-Key-Pins header to restrict which certificates are valid for your domain (so a stolen certificate could only be used by a man-in-the-middle if used on the first connection to your site). You can also use Public-Key-Pins-Report-Only to get notifications for failed Pin validation. Both headers are ...


3

Real-life certificates have a neat concept called revocation. It is a way to propagate (in a secure way) the information that a given certificate, though apparently legit and kosher and with all the correct signatures, should not be trusted anymore. That's a kind of "oops" functionality. In X.509, this uses Certificate Revocation Lists and OCSP. The ...


3

There are two generic points which must be made: PKI is for authentication, not for authorization. "Certificates", be they X.509 or OpenPGP "key signing" (same concept, different format), are meant to bind identities to public keys; they convey the information "Bob's public key is X". Certificates don't work well to manage authorization-like information ...


3

The Authority Information Access extension is used to publish in a given certificate: where a copy of the issuer's certificate may be downloaded; at which address / URL an OCSP server may be found, which will yield fresh revocation information on the certificate which contains the AIA. See section 4.2.2.1 of RFC 5280. Both usages make sense only in a ...


3

In X.509, all revocation goes through objects signed by certificate issuers. The decision to revoke or not revoke is not in the hands of the certificate owner, but of its issuing CA. The CA makes its decision known by including or not including the target certificate serial number in the CRL it produces (ditto for OCSP responses, which are just CRL with a ...


3

You may be able to mitigate this risk by implementing TLSA (also known as DANE), where you essentially store your web servers public key in DNS. This is currently supported in Chrome. I'm unsure if the prior owner's certificate takes precedent over DANE, or vice versa. Considering the security issue that it addresses, it would make sense that all TLS ...


3

If we take as example Verisign's Certification Practice Statement, there does not seem to be any control on the domain ownership end date (see the conditions on domain validation, page 83 and 84: nothing about dates). Actually, the same CPS states that they consider a domain validation to be good for up to 13 months (see page 76), and the maximum lifetime ...


3

Your best approach would be to secure multiple signatures from different trusted authorities. In case one of the private keys is compromised, the file could still be validated. This will incur additional costs, but increase resilience to certificate revocation. Or you could also establish a (more costly yet) procedure of periodic certificate revalidation ...



Only top voted, non community-wiki answers of a minimum length are eligible