Potential bug - Inactive domains, Ssl It extension and Nginx SSL stapling warning

[trialotto]

Username:

TITLE

Potential bug - Inactive domains, Ssl It extension and Nginx SSL stapling warning

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product version: Plesk Obsidian 18.0.49.2
OS version: Ubuntu 18.04 x86_64
Build date: 2023/01/10 23:00
Revision: c825df0ebc392580c3443ca51b28c6cb88be266d

PROBLEM DESCRIPTION

Error notification received by mail, notification of the kind :

nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/opt/psa/var/certificates/xxxxxxxx

Certificates are associated with

a - domains and on a specific server, with DNS pointing to (the domain on another) server,

b - subdomains and on a specific server, with DNS pointing to (the subdomain on another) server,

c - domains and subdomains that are

c.1 - active, (OR)
c.2 - suspended.

BUG 1 : Ssl IT not available on suspended domains, causing various issues - see above

BUG 2 - potential : Ssl IT not working properly with respect to OCSP stapling - see above

WORKAROUND 1 : disable domain

WORKAROUND 2 : follow procedure in https://support.plesk.com/hc/en-us/...issuer-certificate-not-found-for-certificate-

NOTE : workaround 2 is not really nice, since it has to be done manually for individual domains

REMARKABLE : no error notifications by mail of the nginx: [warn] "ssl_stapling" ignored kind when a domain is disabled, as opposed to suspended or active!

STEPS TO REPRODUCE

A - STR - BUG 1 :

A.1 - just suspend a domain

A.2 - open a browser with https://[FQDN-servername]/smb/ssl-certificate/list/id/XX of the offending domain

A.3 - try to open a new tab in the browser with

https://[FQDN-servername]/modules/sslit/index.php/index/certificate/id/XX

and conclude that one

A.4 - is returned to : https://[FQDN-servername]/smb/web/view

A.5 - receives error notification : ! Error. Domain .... is not active. SslIt extension is not available.

A.6 - can NOT use WORKAROUND 2 on domains or subdomains (located on another server), UNLESS the domain is active (read: not suspended or disabled)


B - STR - BUG 2 :

B.1 - create a domain with a subdomain on a source server and point DNS to the source server

B.2 - on the source server, install Let's Encrypt for both the domain and subdomain - with OCSP stapling

B.3 - migrate the domain and subdomain from the source server to a target server

B.4 - point DNS for the subdomain to the target server

B.5 - manually install an old and expired SSL certificate on the subdomain

B.6 - suspend the subdomain on the target server

B.7 - try to get the SSL certificate refreshed : this will not work on both the target and source server

ACTUAL RESULT

See STR

EXPECTED RESULT

It should be possible to renew SSL certificates of domains and subdomains when

1 - the domains or subdomains are suspended

2 - a subdomain (for instance a backup domain or a development / staging environment) is on another server

It should also NOT be necessary to manually switch on/off OCSP stapling, as mentioned in workaround 2.

ANY ADDITIONAL INFORMATION

Please note that I did not have much time to investigate this issue.

There is another issue that is of much more importance........ traffic aiming at ports 7080 and 7081.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Peter Debik]

It should be possible to renew SSL certificates of domains and subdomains when

1 - the domains or subdomains are suspended

No, sorry, if a domain is suspended, it is suspended. It is not a bug that domain-validated SSL-certificates cannot be created on domains that are not actually accessible on the Internet. That is expected behavior.

2 - a subdomain (for instance a backup domain or a development / staging environment) is on another server

Neither a bug, that is also expected behavior. There is a feature request asking to provide the DNS-01 authentication method instead of HTTP-01 method, so that the domain for which a certificate is issued, does not need to reside on the same server. If this is what you mean, please vote for the feature request here:

Issue Let's Encrypt Wildcard (and others) certificate without main domain in SAN (use DNS-01 challenge only)

Currently the Let's Encrypt Wildcard requires that main domain would be hosted on the Plesk server, and pass the HTTP-01 challenge as well as DNS-01 for Let's Encrypt. However for issue the Wildcard Let's encrypt require only DNS-01 challenge. The HTTP-01 limits the causing the issue since not...

plesk.uservoice.com

It should also NOT be necessary to manually switch on/off OCSP stapling, as mentioned in workaround 2.

As I understood it you have uploaded an expired certificate to a domain. Why do you expect this to work and why should this disable OCSP stapling? Under normal circumstances a user would simply prolongate an expired certificate or replace it with a new cert and still expect that his previous OCSP stapling setting continues to work. Changing a certificate has nothing to do with changing OCSP. Sorry, this is not a bug.

 

[trialotto]

@Peter Debik

First of all thank you for your elaborate response.

I will respond to your answers, with those answers being quoted first.

No, sorry, if a domain is suspended, it is suspended. It is not a bug that domain-validated SSL-certificates cannot be created on domains that are not actually accessible on the Internet. That is expected behavior.

To a high degree, it is expected behavior.

Nevertheless, there is a difference between the way the Ssl It extension deals with "suspended" and "disabled" domains : the suspended domains will result in a very odd error notification.

The error notification is not expected behavior (and certainly when taking into account that it deviates from behavior regarding disabled domains).

Also, it SHOULD not be expected behavior : a suspended domain can be reactivated ...... and if the certificate has expired, the reactivated (suspended) domain will be having an invalid certificate during a specific time window.

The above should not be desirable and hence not to be deemed expected behavior.

Neither a bug, that is also expected behavior. There is a feature request asking to provide the DNS-01 authentication method instead of HTTP-01 method, so that the domain for which a certificate is issued, does not need to reside on the same server. If this is what you mean, please vote for the feature request here:

Again, expected behavior to a high degree.

Nevertheless, it is expected behavior from the side of the certifying authority and the way Plesk is working.

However, it SHOULD not be expected behavior.

As far as it concerns "issuing certificates for domains / subdomains on other servers than the source server" ..... it is expected and normal behavior.

As far as it concerns "checking the possibility to renew certificates for domains / subdomains " ...... it is not expected and normal behavior.

It is actually a bug, given the fact that Plesk does not resolve DNS to verify whether the domain or subdomain is residing on the source server.

Please note that it is also a security issue ... no time to explain that here, but it is an important security issue.

As I understood it you have uploaded an expired certificate to a domain. Why do you expect this to work and why should this disable OCSP stapling? Under normal circumstances a user would simply prolongate an expired certificate or replace it with a new cert and still expect that his previous OCSP stapling setting continues to work. Changing a certificate has nothing to do with changing OCSP. Sorry, this is not a bug.

No, you have understood that wrongly.

Plesk allows OCSP stapling to work - even on domains / subdomains with expired certificates.

Again, a bug ...... very likely to related to the fact that Plesk does not resolve DNS to verify whether the domain or subdomain is residing on the source server.

OCSP is persistent by nature and this makes DNS resolution (by Plesk) a bit less meaningful.

Nevertheless, Plesk still allows to work around issues with OCSP stapling by a "switch on/off" workaround - that is not expected behavior of Plesk, it certainly should not be expected behavior from Plesk if the certificates are expired.

As a final note ...... I do not upload expired certificates, I only suggest that one can replicate the situation / issue by adding an expired certificate to a active or a suspended domain or subdomain - otherwise, one would not be able to replicate the whole issue.



In summary, bug or no bug, that is a matter of opinion.

At this moment, Plesk users

1 - making use of a Plesk server that functions as a slave of a master Plesk server will encounter issues,

2 - having suspended domains can (but not always will) get error notifications related to OCSP stapling,

3 - having suspended domains with OCSP stapling related error notifications can remove the error notifications by

3.a - using the "switch on/off" workaround method : this is not a solution of an issue, (or)
3.b - disabling the domains (or subdomains) : this is not a solution,

4 - having reactivated domains that were suspended can (but not always will) get a reactivated domain that will not always reissue certificates properly,

5 - having domains restored from a backup with a certificate that has expired in the meantime will encounter various certificate related issues,

and so on.

In my humble opinion, some careful analysis would be helpful, especially because these are "special situations" that Plesk is not designed for by default.

Hence the common conclusion "expected behavior".......... but "expected behavior" does not mean that something is working properly.

If any, then "expected behavior" should make no difference between suspended and disable domains ...... and there factually is a difference.

That is worthwhile to investigate, to be augmented with the definition of what proper behavior of Plesk should be - for instance, when a domain is located on a source server and a subdomain is located on another server, then Plesk should allow for separate certificate issuing (in all situations, which is not the case).


Kind regards.....