Resolved Let's Encrypt Renewals / Plesk Records Update

[learning_curve]

This almost feels like Part 2 of a very similar issue which was very helpfully solved by Peter Debik but this time it is not the Let's Encypt Renewals themselves, but a certificate records mismatch after their successful renewals

Any NON-Let's Encrypt SSL Certificates that we use are fine. They have 12 Month validity and their renewal process is completely manual and very simple by comparison. The latest issue is only with the regular 3 month renewals of any Let's Encrypt certificates and it seems to be that Plesk is still looking for the OLD Certificate as opposed to the NEW Certificate after a successful renewal, when any associated work is started. In this case, a simple update of the specific Certificate Reference Details for OSCP via the Additional nginx directives area within /web/web-server-settings/

The error, is that the OLD certificate cannot be found within /usr/local/psa/var/certificates/ which is correct, because as part of the renewal process, the Let's Encrypt Extension obviously deleted it Running apachectl -t provides a Syntax OK response but running nginx -t provides the related error report:

SSL_CTX_load_verify_locations("/usr/local/psa/var/certificates/cert-85plFg") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/usr/local/psa/var/certificates/cert-85plFg','r') error:2006D080:BIO routines:BIO_new_file:no such file error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib)
nginx: configuration file /etc/nginx/nginx.conf test failed

which seems to indicate that it's only the nginx config and/or record set that's not successfully been updated.

We cannot use: # /usr/local/psa/admin/sbin/httpdmng --reconfigure-domain <domain-name> as that provides the same error. We cannot use Webserver Configurations Troubleshooter as this also provides the same error. We cannot simply copy the NEW certificate file and then add it back in with the OLD certificate file name, because that would result in certificate duplication and... the NEW certificates are already correctly identified outside of PLESK via all the associated external tests that we have run.

All the correct NEW certificate files are clearly visible in both /usr/local/psa/var/modules/letsencrypt/etc/live/*various*domain*name*subfolders and in /usr/local/psa/var/certificates so we think this can only be a system record set, that's located elsewhere else, that has not yet been updated at the same time all the latest certificate renewals...

So our question is Where do we look to find and how do we update this "mystery" record set to solve the problem? Just Re-Start The Server? It looks like this might will be a regular 3 monthly task too...

 

[Bitpalast]

Are you saying that the domain reconfiguration writes two different outputs to /var/www/vhosts/system/<domain>/conf/ directories for httpd.conf and nginx.conf? With httpd.conf naming a different (the correct) new SSL certificate file and ngix.conf naming the false, outdated file? Can you verify that the configuration files are truly re-written when you run the reconfiguration utility (e.g. check the file datetime)? Because in that case it may no be a problem caused by the Let's Encrypt extension but a problem with the reconfiguration utility. Is the database error free (# plesk repair db -y)?

 

[learning_curve]

Are you saying that the domain reconfiguration writes two different outputs to /var/www/vhosts/system/<domain>/conf/ directories for httpd.conf and nginx.conf?

Yes two separate output files, but both the http.conf and the nginx.conf files are created at the same time/date which is what we would have expected.

With httpd.conf naming a different (the correct) new SSL certificate file and ngix.conf naming the false, outdated file?

No. Both of these files contain the correct NEW file(s) which are present in /usr/local/psa/var/certificates/ (see extracts below)

httpd.conf file certificate reference:
SSLEngine on
        SSLVerifyClient none
        SSLCertificateFile /usr/local/psa/var/certificates/cert-TwiO9v
        SSLCACertificateFile /usr/local/psa/var/certificates/cert-DrZWcx

nginx.conf file certificate reference:
    ssl_certificate             /usr/local/psa/var/certificates/cert-TwiO9v;
    ssl_certificate_key         /usr/local/psa/var/certificates/cert-TwiO9v;
    ssl_client_certificate      /usr/local/psa/var/certificates/cert-DrZWcx;

Can you verify that the configuration files are truly re-written when you run the reconfiguration utility (e.g. check the file datetime)?

Yes, that appears to be the case, by checking the files time/date we can see that this was consistent with our actions.

Because in that case it may no be a problem caused by the Let's Encrypt extension but a problem with the reconfiguration utility. Is the database error free (# plesk repair db -y)?

We didn't need to check if the database was error free (# plesk repair db -y) because thanks to your post, a lightbulb suddenly came on and we realised how / why this had started. We rectified this and 'Boom' all is fixed and well again Details shown in thr next post.

 

[learning_curve]

This issue was actually created by us it appears! There's a link to the Let's Encrypt Certificate renewal yes, but this was to do with any domain that we use, that has both a Let's Encrypt Certificate and OCSP Stapling applied through the /vhost_nginx.conf file i.e. the Additional nginx directives section within the Plesk Panel.

In our current coding, the OLD Let's Encrypt Certificate file is / was referenced here in this code. The first time we attempted to change this on the first domain involved using the Plesk panel, that's where the problem started. The series of checks run by nginx -t must include the domain's /vhost_nginx.conf file (we assume) as well as the https.conf and nginx.conf files? Hence a record set mismatch, as the two Let's Encrypt Certificate files (OLD and NEW) were still be referenced at that specific point because the checks run by nginx -t must be run BEFORE replacing the old /vhost_nginx.conf file with the new one.... Simple really but not until you specifically look for it!

Our fix was to amend the /vhost_nginx.conf files manually for all the domains affected and then run nginx -t again which confirmed no errors and everything sorted. Then normal service was resumed. Running the checks suggested to us in the second post on here, made us realise this could/would be the issue, so thanks again for that.

The task now is to write replacement code within the Additional nginx directives section within the Plesk Panel, that correctly applies OCSP Stapling as before, but which doesn't need amending every three months when domains with a Let's Encrypt Certificate have those renewed.... There's existing posts on this topic in this forum for sure, so that's this week's project then But now it's coffee time