Peer pressure, effectively.
There is a multi-layer structure of trust - the CAs trust the browser makers to include their root certificates, and not remove them without reason. The browser manufacturers trust the CAs to only sign certificates for legitimate requests, and implicitly agree to believe this, with the threat of removing the root certificates of ...
There is no such thing as a non-signed CRL; the signature field is mandatory, and any system that uses the CRL will verify the signature.
In pure X.509, a CRL will be deemed "acceptable" as a source of information about the revocation status of a given certificate E if it is signed by an "allowed revocation issuer": the CRL's signature must match the public ...
By definition, the CA is managing the revocation. In fact, it is a conceptually better way to express thing as: the CA reissues all certificates on a daily basis. The CRL is a kind of data compression: from the point of view of the verifier (say, the Web browser that validates the SSL server's certificate), the certificate is valid as long as the CA says it ...
First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks ...
[Disclaimer: I work as a software developer on the software that powers one of the trusted public CAs, and many corporate internal PKIs]
tl;dr: to my knowledge, there are no formal guidelines for which revocation reason should be used in which situation, it's up to the discretion of the administrator or operator of each CA.
Typically, cert revocations are ...
About the replay attack, the CRL is time stamped with the date of generation and a date for the next update. The nextUpdate date is mandatory in the PKIX profile. If a certificate is revoked, the old CRL can be replayed before nextUpdate if an unsecure channel is used.
This is default behavior for most CRLs. And yes it leads to the issue you have mentioned. In practice many systems have workarounds. Its a delicate situation because CRL bloat is a big issue in of its own.
For SSL this isn't an issue - the expired certificate would be rejected because you expect the server to sign on request.
ADCS (Active Directory ...
The location of the CRL for a specific certificate is embedded into the certificate itself and is visible for all which have access to the certificate, which is at least any client connecting to a server using this certificate. The location is put their by the issuer of the certificate (the CA), i.e. it is not included in the CSR (or gets replaced).
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 ...
No, not in pratice.
No, you can't. CA can revoke certificates it signed/issued only. There is a number of reasons of this choice. Although, RFC 5280 supports delegated revocation authorities (through registering it in the Issuing Distribution Point CRL extension), in practice it is not implemented by crypto clients in most cases.
One simple example: two CAs ...
Not very well.
In theory, the system should work. In practice, it doesn't. The implementations intended to manage revocation - namely CRL and OCSP - both have problems. Most of this answer is based on this article by Alexey Samoshkin, as well as this article by Scott Helme.
What about CRLs?
A certificate revocation list is a remarkably simple way of ...
You can disable it:
To disable OCSP in Firefox:
Go to "Tools (or Menu button) -> Options -> Advanced -> Certificates" and uncheck Query OCSP responder servers to confirm the current validity of certificates.
From the OpenVPN 2 Cookbook:
The OpenSSL ca command generates its CRL by looking at the
index.txt file. Each line that starts with an ' R ' is added to the
CRL, after which the CRL is cryptographically signed using the CA
To reinstate your revoked certificate, you could edit your CA database:
database = $dir/index.txt # ...
In ITU-T-X.509-201210 they are explained in section 18.104.22.168 (Reason code extension) as:
– unspecified can be used to revoke certificates for reasons other than the specific codes.
– keyCompromise is used in revoking an end-entity certificate; it indicates that it is known or suspected
that the subject's private key, or other aspects of the subject ...
Which CRL should the crlDistributionPoints contain to for the intermediate CA? The root CA's CRL or the intermediate CA's CRL?
The crlDistributionPoints must point to the CRL which will contain the revocation for the certificate itself. Thus in case of an intermediate CA this will probably be the CRL signed by the issuer CA, although it can be any other CA ...
There is no method to "unsuspend" a certificate in openssl on the CLI that I am aware of. And the following quote may give you a bit more guidance:
Martin Abalea, OpenSSL mailing list, 2008-10-13, Re: Put certificate on hold:
Reading the X.509 recommendation (downloadable for free from the ITU-T
web site) tells us that a certificate can be "un-holded" ...
The 'removeFromCRL' reason code indicates that the certificate is, in fact, not revoked. The idea behind 'certificateHold' is to make a suspension, not a revocation: the PKI declares that the certificate should not be used until more information is made available (in a subsequent delta or full CRL), while not fully revoking the certificate, because ...
Expiration date is "baked" into certificate itself, so even if time on client is incorrect this wouldn't cause server to mistakenly accept the certificate. Server clock, on the contrary, have to be correct.
Now, whether or not it is safe to remove expired certificates from the CRL depends on how server verifies certificates and, in particular, whether it ...
You need to specify -crl_check (and spell verify correctly) AND have both the CA cert and the (applicable) CRL in your truststore. There are two ways to do that:
concatenate cacert.pem and crl.pem into one file and use that for -CAfile.
put or link the cacert PEM file in a directory using the name $hash.0 where $hash is the hash of the cert subject (which ...
The unique problem induced by hard-fail certificate is that it introduces an additional choke-point outside the control of the site owner but in the critical path for site function, one which typically is not particularly well-resourced.
Since all secure sites require TLS certificates, and since most certificates are issued by one of only a small number of ...
In a definition of certificate profile for OCSP Signer certificate, should I define CRL distribution points or AIA OCSP URI?
RFC 6960 allows such configuration, however in practice there is no real benefit, because you will have other 3rd party source to validate OCSP signing certificate. When OCSP signing certificate includes id-pkix-ocsp-nocheck ...
CRL distribution points are location that the client must be able to resolve to a file. If the client is unable to obtain that file, it will go to the next location.
In order to obtain that file, the client must be able to:
Understand the schema of the endpoint (HTTP, LDAP, File, Whatever...)
Resolve the host name (if appropriate).
Contact the host name ...
You shouldn't really install the webserver (IIS in your case) on the same server as the CA any more than you should install the CA on a server which provides other services (DCs are a common one).
Instead, stand-up another server for IIS. Better still, stand-up two and load balance them.
Create a share (such as cdp$) on the IIS (or IISes if that's the ...
Delivering the existing CRLs is a significant cost for the CAs!
Here you can see some information about costs.
[...] CRL grow to approximately 4.7MB in size from approximately 22KB [...] around 40Gbps of net new traffic across the Internet [...] the traffic to deliver the CRL would have added $400,000USD to Globalsign's monthly bandwidth bill
Adam Langley (google) wrote a reply to GRC's accusations. it can be found here: https://www.imperialviolet.org/2014/04/29/revocationagain.html
Revocation still doesn't work (29 Apr 2014)
I was hoping to be done with revocation for a bit, but sadly not.
GRC have published a breathless piece attacking a straw man argument: “Google tells us ....
[...] is it because CRL's are seen as static files [...]?
Wouldn't this also be an easy way for hackers to withhold updates to a CRL (as long as the old one's still valid)?
Yup. Both limitations are known. And from how I read the RFC, both are deliberate design choices.
From RFC 5280, section 3.3 Revocation: (emphasis mine)
An advantage of this ...
In the end, it depends on the S/MIME software you are using.
Normally, when signing, the software doesn't make any lookup at CRL...it's supposed that you are using a valid certificate for it.
The email recipient (and thus his mail software) is the one responsible for check the email signature (if you only encrypt and not sign the email, there is no reason ...
A Certificate Revocation List (CRL) serves to check that the Public Key of an entity, even if signed by a legitimate, recognised Certification Authority (CA), has not ben revoked since it was issued.
A Public Key is used (and thus the CRL is checked) in two occasions:
a. When you want to encrypt an outgoing email you use the Public Key of the recipient
I completely agree with you -- you seem to understand the complexities of the issue.
Let's look at the extremes:
CRL Lifetime = subCA Lifetime. ==> the CRL is completely useless; you have no ability to revoke the subCA because so long as the previous CRL is within its validity period, clients have no reason to fetch a new one, unfortunately that's how the ...