It's an old but still not common feature, but I guess it will grow popularity in future - OSCP Must Staple is an additional instruction bundled inside the TLS certificate which instructs the browser that the server MUST send an OSCP Stapling information.
Question:
Is there a way to implement it in DA Lets Encrypt certificates?
Explanation:
When a web server has a hacking suspicion, it revokes all certificates and issue new. This is to ensure that nobody will reuse their certificate to make a malicious website (for example in MiTM attack scenario). The problem is that the clients must somehow know that a certain certificate is revoked.
The historical solution is to use CRLs (certificate revocation lists) which are a responsibility for the client to fetch and use. The issue is that as web encryption grown drastically, CRLs also became pretty large files. So it does not scale well. And it is not fetched and updated very frequently (usually TTL 24 hours).
OSCP stapling came as a solution. What it does is that the webserver contacts the CA, fetch a digitally signed insurance that their certificate is not revoked (which has a certain time to live after which it becomes invalid/expired) and send that digitally signed insurance message to the client during their TLS handshake. It simplifies the process for the client. When somebody eventually hack a server certificate, he can only use it with the last valid OSCP stapling that he eventually got - and it will expire, so his hack will be short lived.
Enabling OSCP stapling is pretty easy and straight forward. In case of Apache, just uncomment those lines in httpd-ssl.conf:
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(512000)
The problem. While OSCP stapling is great, it has an issue. It is that not all webservers do support it and not all browsers request it. Or simplified: it's not obligatory to use it. So what hackers can do with a hacked certificate is to NOT send OSCP stapling at all, even if the client requests it. What all browsers do in such case? You guessed - they say "Oh, well, this server do not support OSCP stapling, so we will just assume that everything is OK" (and rely to their CRL which is fetched rarely and is therefore eventually outdated). Therefore OSCP stapling itself is a good thing but it is not increasing security at all and we still rely on CRLs.
What is OSCP Must Staple? It comes for the rescue. There is a message within the TLS certificate itself which indicates that the server who uses that certificate MUST include OSCP stapling data. That way the hackers cannot skip sending it... and problem solved.
The issue is that currently only Firefox respects it. But hopefully in future all browsers will do.
P.S. Obviously SSLStaplingReturnResponderErrors must be On if OSCP Must Staple should be used because elsewhere it will return misleading error message to the client in case the OSCP CA server is temporarily not working.
P.S.2. And usually you should consider enabling mod_md as it is much better implementation of OSCP Stapling than the one in mod_ssl: https://github.com/icing/mod_md
Question:
Is there a way to implement it in DA Lets Encrypt certificates?
Explanation:
When a web server has a hacking suspicion, it revokes all certificates and issue new. This is to ensure that nobody will reuse their certificate to make a malicious website (for example in MiTM attack scenario). The problem is that the clients must somehow know that a certain certificate is revoked.
The historical solution is to use CRLs (certificate revocation lists) which are a responsibility for the client to fetch and use. The issue is that as web encryption grown drastically, CRLs also became pretty large files. So it does not scale well. And it is not fetched and updated very frequently (usually TTL 24 hours).
OSCP stapling came as a solution. What it does is that the webserver contacts the CA, fetch a digitally signed insurance that their certificate is not revoked (which has a certain time to live after which it becomes invalid/expired) and send that digitally signed insurance message to the client during their TLS handshake. It simplifies the process for the client. When somebody eventually hack a server certificate, he can only use it with the last valid OSCP stapling that he eventually got - and it will expire, so his hack will be short lived.
Enabling OSCP stapling is pretty easy and straight forward. In case of Apache, just uncomment those lines in httpd-ssl.conf:
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(512000)
The problem. While OSCP stapling is great, it has an issue. It is that not all webservers do support it and not all browsers request it. Or simplified: it's not obligatory to use it. So what hackers can do with a hacked certificate is to NOT send OSCP stapling at all, even if the client requests it. What all browsers do in such case? You guessed - they say "Oh, well, this server do not support OSCP stapling, so we will just assume that everything is OK" (and rely to their CRL which is fetched rarely and is therefore eventually outdated). Therefore OSCP stapling itself is a good thing but it is not increasing security at all and we still rely on CRLs.
What is OSCP Must Staple? It comes for the rescue. There is a message within the TLS certificate itself which indicates that the server who uses that certificate MUST include OSCP stapling data. That way the hackers cannot skip sending it... and problem solved.
The issue is that currently only Firefox respects it. But hopefully in future all browsers will do.
P.S. Obviously SSLStaplingReturnResponderErrors must be On if OSCP Must Staple should be used because elsewhere it will return misleading error message to the client in case the OSCP CA server is temporarily not working.
P.S.2. And usually you should consider enabling mod_md as it is much better implementation of OSCP Stapling than the one in mod_ssl: https://github.com/icing/mod_md
Last edited: