• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • Support for BIND DNS has been removed from Plesk for Windows due to security and maintenance risks.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS.

Issue Potential issue with OCSP stapling

Bitpalast

Plesk addicted!
Plesk Guru
Server operating system version
Alma 8
Plesk version and microupdate number
18.0.69 #3
On # nginx -t we are seeing lots of these lately:
Code:
nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/usr/local/psa/var/certificates/scftPr4m0"

It means that the web server is configured to use OCSP stapling, but the SSL/TLS certificate used does not include an OCSP responder URL, so OCSP stapling cannot work. The SSL certificate does not contain an Authority Information Access (AIA) field with an OCSP URL, which is required for OCSP stapling. Without that, the server has no place to fetch the OCSP status from.

It seems that this affects all SSL certificates generated through the Plesk SSLIt extension. I am not sure whether this is a misconfiguration here or a bug, but given the large number of certs affected, I tend to think of it as a bug. The thing is, that previously that warning was not shown, e.g. several weeks ago. Something must have changed since then. Maybe an update? I am not sure when it started.
 
Thank you for the link! Very interesting. So it seems we've been very lucky that the web servers did not start hanging due to an impossible OCSP verification process as the verification servers went offline? Plesk should consider to update the extension and to remove the OCSP option from it.
 
Thank you for bringing that up. I know this case was previously discussed by our team, but, as of this point, I don't have a clear answer on what actions will be taken. I will follow up with more details shortly.
 
Should I disable OCSP stapling for all domains right now to avoid failures when the automatic renewal occurs?
 
@King555 , I believe it shouldn't be an issue disabling OCSP stapling, but if your SSL renewal is not due in the upcoming few days, let me clarify that with our team first.
 
The only (negative) effect that the OCSP stapling option has and ever can have, is a warning message when reloading or restarting the nginx webserver.
So yes, it may not be nice, but it will never break your system.

Btw. for self-signed certificates you'll get the same warning, as these certificates do also not contain an OCSP URL.

I do expect that Plesk will drop this menu option or at least remove it from their recommended preset.
Would be nice if the Panel would auto-detect the presence of an OCSP URL in the selected/active certificate and hide/remove the stapling option in these cases.
 
A bug with ID EXTSSLIT-2188 has been registered. I cannot provide any ETA yet. Our team confirmed that disabling OCSP Stapling holds no additional risks.

Until the fix is released, you can disable it:

  1. For individual domains by toggling off "OCSP Stapling" in Domains > example.com > SSL/TLS certificates
  2. For all domains by running:

    plesk bin site -l | while read i; do plesk ext sslit --ocsp-stapling -disable -domain $i; done
 
The only (negative) effect that the OCSP stapling option has and ever can have, is a warning message when reloading or restarting the nginx webserver.
So yes, it may not be nice, but it will never break your system.
Not really. One problem is that when the servers are unresponsive yet the webserver for some reason might still want to address them, on systems with many websites an Nginx reload or restart will hang and eventually run into a timeout. In other words: The web server might not restart. This was a known issue once when some nameservers stopped resolving their OCSP server domain names.

Another problem is shown here: Issue - Certificate verification failed
The cause for that is the missing OCSP response, so some users are unable to update components of their OS at this time.

Would be nice if the Panel would auto-detect the presence of an OCSP URL in the selected/active certificate and hide/remove the stapling option in these cases.
Absolutely necessary!

All in all I think it is safe to call turning of OCSP service is a stupid decision by Let's Encrypt. And it foreshadows a path we don't want to see: That sooner or later the whole free SSL project will stop, forcing hundreds of millions of users to buy overpriced certificates from commercial vendors again.
 
  • Like
Reactions: mow
A bug with ID EXTSSLIT-2188 has been registered. I cannot provide any ETA yet. Our team confirmed that disabling OCSP Stapling holds no additional risks.

Until the fix is released, you can disable it:

  1. For individual domains by toggling off "OCSP Stapling" in Domains > example.com > SSL/TLS certificates
  2. For all domains by running:

@Sebahat.hadzhi

This is a "workaround" and NOT a solution.

In fact, @Bitpalast was right by stating that it is a bug.


The error notifications resulting from nginx are the result of failures related to the OCSP Must Staple extension, as can be deducted from

  • May 7, 2025
    • Prior to this date we will have added CRL URLs to certificates
    • On this date we will drop OCSP URLs from certificates
    • On this date all requests including the OCSP Must Staple extension will fail
  • August 6, 2025
    • On this date we will turn off our OCSP responders

implying that

1 - responses from the OCSP service should still work,

2 - responses should not lead to error notifications, UNLESS OCSP Must Staple extension is activated.


The bug here is that the OCSP Must Staple extension is activated, even though OCSP Stapling would - in most cases - work without that extension.


Another bug here is that OCSP is used, even though CRL could have been used by Plesk since 2022 !!!


In my humble opinion, it should have been predictable that CRL would replace OCSP and that Plesk should have adapted the SSL it extension.

When working on a "fix", try to make sure that the CRL mechanism is - finally - used by the SSL it extension.


Kind regards.....
 
@Everyone,

This statement

Not really. One problem is that when the servers are unresponsive yet the webserver for some reason might still want to address them, on systems with many websites an Nginx reload or restart will hang and eventually run into a timeout. In other words: The web server might not restart. This was a known issue once when some nameservers stopped resolving their OCSP server domain names.

might be a bit confusing.

First of all, OCSP related issues concern all web servers, at least in theory and - in most cases - also in practice.

Plesk essentially comes with two flavors of web servers : Apache and stand-alone Nginx.

Nginx can be a stand-alone web server OR a reverse proxy (in front of the web server) : in most usage scenarios, Nginx is a reverse proxy.

The current OCSP issue is - factually - limited to Nginx error notifications.

This simply means that Nginx, as a stand-alone Nginx instance OR a reverse proxy, is giving some notifications.

If Nginx is a reverse proxy, then the part "the web server might not restart" is not correct : Nginx (as reverse proxy) will restart!

If Nginx is a stand-alone web server, then Nginx (as stand-alone web server) will - often - restart : only in highly exceptional cases, restart will fail.

If Apache is the web server ......... well, then failures to restart are to be expected.


In summary, it is important to know whether you use Nginx as a reverse proxy or a stand-alone web server.

A clear distinction should be made between the two of them, since the likelihood on and amplitude of (potential) OCSP related issues are completely different between the stand-alone Nginx and the Nginx as a reverse proxy.


This statement

All in all I think it is safe to call turning of OCSP service is a stupid decision by Let's Encrypt. And it foreshadows a path we don't want to see: That sooner or later the whole free SSL project will stop, forcing hundreds of millions of users to buy overpriced certificates from commercial vendors again.

is both right and wrong.

Let's Encrypt made an excellent decision, when (only) looking at the security aspect of OCSP Stapling, since the CA (Certificate Authority) can and WILL gather all kinds of information that you do not want to share with the CA.

Moreover, Let's Encrypt does not mention the - relevant - fact that any CA will become more and more a SPOF (Single Point of Failure) in a system that should increase (and not reduce) security : any hack of any CA will expose lots of information (and this has happened before).

People should make a trade-off when deciding to turn OCSP Stapling on OR off : security will increase by the OCSP mechanism itself, but security will also decrease by allowing the CA to gather information that should be private.

What makes Let's Encrypt's decision excellent?

Well, the simple fact that they do not want to be legally obliged to store specific information ....... with that kind of motive, one could really not object to a decision that involves shutdown of OCSP Stapling.

What makes Let's Encrypt decision a bit less ideal?

Well, if OCSP Stapling is replaced by CRLs (at Let's Encrypt) and other mechanisms (from other companies) .......... then there is uncertainty about what the new industry standard is going to be AND there is space for specific companies to enforce their method as the industry standard.

It is not going to happen that the free SSL projects will stop.

It is also barely relevant.

Nevertheless, it will become relevant that other companies will offer free or cheap SSL certificates.

And there lies the actual problem.

Consider Google ..... offering alternatives to Let's Encrypt (free) SSL certificates would leave us with Google as the CA - without doubt, all data will be used for tracking purposes, which is the core business of companies like Google.

The decision of Let's Encrypt is excellent and honest, but it also will result in space for other (less honest) companies to go into the SSL certificate business.


In my humble opinion, we should not worry about the decision of Let's Encrypt, but we should about the consequences of that decision.

No, it is not very likely that free SSL certificates will become a "thing of the past".

Yes, it is very likely that commercial motives will enter the domain of both paid-for and free SSL certificates - there will always be an incentive to earn money with data gathered, if that data can be gathered - for instance, by becoming a CA that is legally obliged to store specific data.

Nevertheless, even though there might be companies wanting to leap into the market that is partially abandoned by Let's Encrypt, it is still safe to say that all mechanisms (like CRLs) provided by Let's Encrypt are better than the alternatives - Let's Encrypt simply is a more honest project / company.


All of the above is just some food for thought!

Kind regards ...
 
@trialotto , thank you for the input. It is forwarded to our team for further review.

I believe in the scope of this bug report it is planned to rework the extension logic so it will automatically disable OCSP stapling and will not allow it to be enabled if the certificate does not have an OCSP responder URL. I will double-check if we plan on introducing CRL support along with it and I will follow up on that next week.
 
@trialotto , thank you for the input. It is forwarded to our team for further review.

I believe in the scope of this bug report it is planned to rework the extension logic so it will automatically disable OCSP stapling and will not allow it to be enabled if the certificate does not have an OCSP responder URL. I will double-check if we plan on introducing CRL support along with it and I will follow up on that next week.
@Sebahat.hadzhi

The CRL implementation is a bit tricky.

Let me explain in the most simplest of terms, for the benefit of all Plesk Forum users and for the general understanding of OCSP and its alternative, the CRLs.


OCSP is effective, in the sense that it is - simply stated - equivalent to : "one CRL per certificate".

CRL is a (full) list of all certificates that are revoked.

CRLs are tricky in the sense that they are "(complete) lists per CA".

CRL would become very inefficient if that list would contain hundreds of millions of revoked certificates - this is actually the case for many CAs.

In the past, a solution has already been presented to overcome this inefficiency of CRLs.


A (general) solution is browser-based CRLs, which are supported by all (or most) modern browsers.

This solution (or approach to a solution) is highly browser-specific.

Nevertheless, there has been a tendency (or force) to push centralization - a tendency enforced from the start by Apple (Safari) and Mozilla (Firefox).

Not sure whether the CCADB can resolve the inefficiency of huge CRLs by distributing URLs to those CRLs of each CA, but it might help a bit.


In general, the term "browser-based" - luckily - implies : no need to worry, no need to implement something "on the server side".


The whole problem here is that one diverges from "efficiency" (read: OCSP, one CRL per certificate) to "less efficiency" (read: CRLs, as such huge lists).

Sure, OCSP stapling can be disabled - but it is not wise, as long as the OCSP is still running : it is the most efficient way to check for revocation.

Sure, not allowing OCSP stapling if the certificate does not have OCSP responder URL, that seems to be logical : is it?!?

The answer to that last question : no, it probably is not, but we will have to, since the OCSP responder URL will disappear from the Let's Encrypt certificates.


People have been dealing with the error notification "no OCSP responder URL found" in the past, with some (odd) workaround as a result.

One of the workarounds has been to use some certificates that were installed "server-side" - not wise, in terms of security, but it works.

This particular workaround can also provide a suggestion for Plesk Team to implement CRL support on the server-side : if one really wants to do a check on the server-side, one could consider to maintain CRLs on the server.

It sounds a bit obsolete, if browser-based CRLs are supported, right?

It actually is not .... server-side CRLs can help logging valuable information that would otherwise not be gathered (since only present on the browser-side).

More importantly, server-side CRLs can speed up processes and increase security considerably.


In summary, CRL implementation can be a bit tricky.

It is not about the technical implementation, which should be quite straightforward.

It is tricky in the sense that one has to - carefully - consider the objectives that one wants to achieve, whilst making a good trade-off with has to be done on the server-side and what has to be done on the browser-side.


All of the above is food for thought.

To give Plesk Team some more food for thought, I simply want to mention that - especially - Nginx can be used to create a "OCSP alike" mechanism with one CRL per certificate on the server-side, for all certificates used on that server (and the remainder, if any, should rely on browser-based CRLs).

In my humble opinion, the latter option could be (or should be) investigated.


Kind regards....
 
Let's Encrypt made an excellent decision, when (only) looking at the security aspect of OCSP Stapling, since the CA (Certificate Authority) can and WILL gather all kinds of information that you do not want to share with the CA.
Isn't OCSP Stapling explicitly designed to prevent the CA gathering user information, which it would get if each browser would have to connect some revocation database on their own instead of the webserver doing it for them and deliver the recent revocation status stapled to the certificate, so that said database only sees the IP of the webserver which it would know anyway?
 
Isn't OCSP Stapling explicitly designed to prevent the CA gathering user information, which it would get if each browser would have to connect some revocation database on their own instead of the webserver doing it for them and deliver the recent revocation status stapled to the certificate, so that said database only sees the IP of the webserver which it would know anyway?
@mow,

Well, yes and no.

The original idea (or concept) was - essentially - to increase security : making information available that allows the identification of "unsafe" certificates, with the "(advantageous) byproduct" of additional minimization of the attack surface by means a reduction of sensitive information being exchanged.

So yes, the intention was "prevention", but that was not really the primary objective - it was, so to speak, a "byproduct" by design.

But no, any OCSP service designed to be responding to requests is not equal to minimization of the attack service - OCSP Stapling by design is not more or less safe : it will increase the attack vectors, which - ironically - also include information that would normally be considered as "safe" (and actually is "unsafe").

For instance, having knowledge of revoked certificates is (one the hand) a validation method of "safe" certificates and (on the other hand) an information source.

A source of information that can be used or, if you will, misused.

Use (or misuse) can take place everywhere in all separate steps of certificate authentication, notably on all sides where these steps are occurring.

Use (or misuse) is hence not limited to the CAs.

Nevertheless, the irony is that the CAs have to gather the information, in order to make the (design of) OCSP stapling work - the CAs will get data with all kinds of requests and this data is stored in order to make OCSP stapling a viable (validation) process.

One of the solutions to the requirement that CAs will have to gather information is that CAs do not store the obtained data permanently.

With that possibility (read: not storing data permanently) in mind, OCSP stapling was designed as the (proper) method of validation of "safe" certificates, by eliminating "unsafe" certificates, amongst which revoked certificates.

If you ask me, it is a choice in the light of efficiency (otherwise OCSP stapling would be rather inefficient and unmanageable) for most CAs, but some CAs did agree with the OCSP stapling design for other reasons - they wanted to gather data and some CAs did not really have "nice objectives or intentions".

Let's Encrypt was one of the CAs with good intentions, essentially looking for a good system, with "good" being defined by the limitations of the system.

However, that possibility (read: not storing data permanently) is more and more absent.

The simple fact is that some CAs are simply obliged by law to gather and store data ...... and even share this data with governmental bodies.


In summary, Let's Encrypt seems to have made an excellent decision in the sense that they sticked to their firm belief that it is not the role of the CA to gather and store data - they are still aiming at "prevention" (where and whenever possible).

So, yes, any design might have a specific intention, like prevention of data gathering (by CAs or other parties).

However, also a no, since the nature and limitations of any design and/or changes in applicable law might simply change the implications and consequences of any design, hence creating a discrepancy between the original intention and the factual implications/consequences.


OCSP stapling might have been a good concept with a flawed design that could be improved to combat misuse by those parties that wanted to gather information ......

....... but it became rather clear that that good concept was already doomed from 2022, when the deliberate choice was made to actively maintain CRLs and even push the usage of those CRLs.

In my humble opinion, it remains strange to note that the companies and governments that we rely upon for safety ..... are using "safety mechanisms" to get information - I am not sure whether there is perfect causality between information and safety.


Kind regards...
 
Back
Top