Tag Info

Hot answers tagged

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 ...


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

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

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

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 ...


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

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 ...


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 ...


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

"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

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

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 ...


3

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, ...


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

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

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

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 ...


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

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 ...


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

PKI has two elements: the technical protcols and the procedures we build around them. In the technical realm, things are pretty clear: you got mechanism that allows you to decide what to trust, when under what condition and how to communicate (most) changes in that trust system (CRL, OCSP, etc.). These technical elements do not, however, cover the ...


3

Since I can't comment, apparently, I want to clarify a couple of points. CT does not require all browsers to use it: there is a herd immunity conferred even if only one browser does it. And, BTW, Chrome's next release includes CT support. Webservers do not have to change to support CT - CAs can include the SCTs in issued certificates. Some CAs already do ...


2

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 ...


2

No where in the standards that I can recall (I contributed to 2560 and am an author to 5019) does it say you can not serve responses for yourself, that said as you point out doing so is useless since you cant trust the response in that scenario. Are you sure that is what you are seeing though; remember that OCSP "good" doesnt mean issued it means "not ...


2

I'm afraid the answer will be "it depends". How many simultaneous requests can your server(s) handle? How important is it to your organization that information about a revoked certificate be propagated quickly? If you put the Max-age setting too high, a revoked certificate will still be able to connect for up to the max-age setting. If you put it too low, ...


2

If the root CA is offline then the root CA is offline: it has no network. This implies that whenever a CRL is published, a manual intervention is needed to put it on a connected host. At that point, you can put it manually in three places if need be. The "Authority Information Access" (AIA) and "CRL Distribution Points" (CRLDP) extensions are information ...


2

I think the reason this question is difficult to answer is because it is the wrong question. You cannot evaluate appropriate expiration times in isolation from the 'thing' being protected. There are no absolutes here. What you really need to determine is what is the maximum expiration time we can accept as being long enough to achieve maximum convenience for ...


2

Some operating systems, including Windows, want to enforce verifications of signatures of DLL. The verification entails validating the signature against the signer's public key, which is found in the signer's certificate, which itself needs to be validated. Certificate validation includes revocation status check. In practice, a Windows OS validating a ...


2

Uwe Plonus is right. The CA always provides a revocation-list (CRL) in wich all revoked certificates are listed by their serial number and other information like the datetime when a crt was revoked. See http://www.openssl.org/docs/apps/crl.html# for further information.



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