No. Revocation is an active event, not something that passively or automatically happens. Expiration is passive, though. An expired cert is no longer valid, so there's no need to stick it in a CRL or update OCSP.
If the purpose of your checker is only to parse OCSP, then no, you don't need to check the dates on the cert, because that's not part of OCSP. If ...
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 ...
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 ...
You MUST check the expiration date first. You can do that locally, without creating a connection to the OCSP server and spending network resources at both your end and OCSP server's end. (And yes, I regularly deal with overloaded OCSP servers.)
And no, an expired certificate is not automatically revoked. In a lot of cases (as in dealing with timestamped ...
OCSP stapling is more efficient than regular OCSP and provides better privacy.
The OCSP protocol is used to determine if a certificate is still valid or has been revoked. Say, you want to securely connect to a website via TLS. To be certain that the certificate has not been revoked or expired, your browser can issue an OCSP request to the corresponding ...
According to nginx documentation the ssl_trusted_certificate parameter contains trusted CA certificates used to verify client certificates and OCSP responses if ssl_stapling is enabled and the list of these certificates will not be sent to clients.
Therefore I think that what ssllabs calls "Additional Certificates (if supplied)" are the certificates in the ...
This information is exposed when you use openssl x509 with the -text option:
$ openssl x509 -in cert.pem -noout -text
It's visible in the x509v3 extensions block:
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
If you are only interested in this information, you can ...
You have the following setup:
server.crt is issued by sub-ca.crt, sub-ca.crt is issued by root-ca.crt
OCSP response is signed by root-ocsp.crt which was issued by root-ca.crt
The process to validate a OCSP response is described in RFC 2560 section 22.214.171.124. (now obsoleted by RFC 6960) In short the OCSP response must be
either signed by the issuer of the ...
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 ...
OCSP provides a dynamic mechanism for checking whether a given certificate has been compromised or not and, in case it has been compromised, after what date (and time) should signatures using this certificate considered unsafe (basically, it is a dynamic version of CRLs).
This has several consequences:
OCSP responses SHOULD be backdated in case they ...
It seems their OCSP-cert has expired on September 10th.
Version: 3 (0x2)
Serial Number: 132 (0x84)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=NL, O=Digidentity B.V., CN=Digidentity Services CA - G2
Not Before: Sep 20 10:40:55 2012 GMT
Not After : Sep 10 ...
GeoTrust (and RapidSSL) certs have two trust paths.
There is a root cert for GeoTrust Global CA valid 2002-05-21 to 2022-05-21 and now widespread,
and also a "bridge" cert for the same CA valid 2002-05-21 to 2018-08-21 chaining back to Equifax Secure Certificate Authority which as you saw is valid 1998-08-22 to 2018-08-22.
See my (updated) answer to google ...
The only solution I was able to find is to use either Firefox or Internet Explorer, and enable hard-fail.
Go to Options -> Advanced -> Certificates-> Validation
Check the box for "When an OCSP server connection fails, treat the certificate as invalid"
For Internet Explorer:
Can only be enabled in registry using ...
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.
The usage of OCSP Stapling is actualy the solution to "hide" the visitors from CA's eyes. And of course also for reducing the load on CA's OCSP responders.
OCSP Stapling's principle is that the web server is getting the OCSP response from CA's OCSP responder on behalf of the visitor, so CA can't log the visitor's IP addres, time of the visit or anything ...
The best I can find is from a draft version 2 of X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP proposal, which later became RFC 2560. It states that:
The requester signature is used to authenticate the requester to the
OCSP Responder. It is used in conjunction with the requester
certificate extension defined below.
Think about it like this. You go to the grocery store to buy milk. Would you check for recalls on milk to see if the milk is expired? No! You'd just check the expiration date. You know it's expired by the expiration date alone. It's the same case with certificates. You should be checking the date to see if it is expired. If it has not expired then you can ...
The webserver behaviour described is undesirable and appears to be due to a Apache configuration default for the SSLStaplingReturnResponderErrors setting. There have been numerous online posts questioning the logic behind these configuration defaults.
Additionally, alternative webserver implementations do not follow suit. Caddy will not serve stapled ...
OCSP responses may be signed not only by the CA itself, but also a designated OCSP signer. That's an X.509 certificate issued by that CA with the OCSPSigning (126.96.36.199.188.8.131.52.9) extended key usage.
For details see RFC 6960, section 184.108.40.206.
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 ...
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 ...
When I open this page in Chrome it opens normally. Why does Firefox object?
Chrome only does very limited checking of revocations, especially it does not use OCSP any longer. Firefox instead does OCSP checks.
The browser sends a query to an OCSP server to verify the current validity of it's ssl/tls certificate.
Yes, with OCSP the OCSP could figure out which site the user visits. It cannot figure out which URL but it can determine the certificate the browser tries to access and thus which site. OCSP requests are not done for each HTTPS request to the same site ...
AFAIK, it shouldn't be possible to create a certificate that "seems to be issued by the original CA" in such a way that even an OCSP request occurs. At the point where the check happens (if at happens at all, after all it's e.g. considered practically broken on the web because on servers being unreliable in handling the requests) the certificate should ...
OCSP is a way for the CA to INVALIDATE specific certificates. A browser will also check the signature of the supplied certificate against the CA's root certificate (possibly in a few steps, the certification chain), this is done completely locally.
So in short, no it is not possible to make a fake certificate look valid without replacing the CA's root ...
You just answered your question, it is possible (though, strongly discouraged). Even RFC6960-conformant clients should support this scenario.
For example, Microsoft CryptoAPI allows this scenario even when OCSP signing certificate chains up to different root (which must be trusted) by default. Source: What’s New in Certificate Revocation in Windows Vista ...
Somethings to add to @Arminius' answer:
client initiated OCSP request and OCSP stapling still share a problem - non responsive OCSP responders. Whether it's the client, or the server that is being certified, that's getting the OCSP response, the responder is the same. If the responder is down, the whole security guarantees fall apart.
The absence of a ...
The connection to the OCSP responder does not need to be protected by HTTPS (it often is HTTP only) and the OCSP responder does not even need to be the authoritive source for the OCSP response, it can just forward responses it got from somewhere else. The signature instead is done by the authoritive source.