Tag Info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I don't thing that you should put the problem like this- rekey vs revoke. Re-keying is done when you move your website to a new server, your server crashed, or you lost your private key. You also need to re-key to add or remove subject alternative names (SANs) in a UCC SSL. (source) When you ask for a new key pair, the old certificate is ...

There are really a few options. You could try to use a hardware security manager that would lock the key away and only allow signing. This would prevent any of the IT staff from accessing the key itself, but is a lot more complicated to set up. You can also (and really should in either case) set up intermediate certificates so that the root isn't ...

Well if you want to know what other people use, I've used OpenVPN w/ clients who authenticate via ldap to an active directory. When the person leaves, their account is disabled and they have access to nothing. In that same environment we also issue machine certs to every workstation, so that workstations that have joined our domain can access a different ...

A "normal" setup with Microsoft's Certificate Services involves two CRL files: a base CRL and a delta CRL. The base CRL is destined to be referenced from a CRL Distribution Points extension in the issued certificate. The base CRL will contain a Freshest CRL extension which itself points to the delta CRL. Whenever a new base CRL is issued, a new delta CRL is ...

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

Self signed root certificates shouldn't have AIA -- there's no CRL that will be checked by PKIX conforming implementations. If you have a service that uses certificates issued by your own root, but that must be verifiable using only the other CA then the intermediate should have AIA extension -- it's not a root certificate any more. To illustrate (correct ...

Here's a certificate that has just a directoryName distribution point. I guess it's saying to connect to an LDAP server to get the CRL? -----BEGIN CERTIFICATE----- MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 ...

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

I've read the standard and it looks to me like the BC is not implementing it properly. The RFC 5280, section 6.1.3, item (a): (3) At the current time, the certificate is not revoked. This may be determined by obtaining the appropriate CRL (Section 6.3), by status information, or by out-of-band ...

I'd reccomend moving this over to SO, since it is code related - there may be a workaround; but it appears that the issue is more related to the validation of a revoked certificate post publication of a new CRL that contains that certificate. I'm not 100% on your scenario - so please correct my assumptions if needed. Also recall that you need to be able to ...

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