Failed download certificate not detected.

[webservicebe]

Last night one of my certficates on a webserver was renewed.
In the last step (downloading the certficate) it went wrong due to a busy webserver at Let's Encrypt.
This was not detected by getssl, I presume the code from Let's Encrypt was not 500 but 503, so the error was saved as .crt.
Resulting in a crash of apache at our webserver, so all sites went down due to a buggy certificate.

Solution:
Just add a final check (like openssl x509 -in <new_crt> -text -noout) between cert_archive and cert_install.
In that case the bad certficate is still in the archive and checks can be done afterwards.
Alternative: raise an error if http status code from Let's Encrypt is not 200

Log from getssl:

Verification completed, obtaining certificate.
Requesting Finalize Link
Requesting Order Link
Requesting certificate
Certificate saved in /root/.getssl/**mydomain**/**mydomain**.crt
copying domain certificate to /usr/local/nginx/conf/letsencrypt/**mydomain**.crt
copying private key to /usr/local/nginx/conf/letsencrypt/**mydomain**.key
copying CA certificate to /usr/local/nginx/conf/letsencrypt/chain.crt
copying full chain to /usr/local/nginx/conf/letsencrypt/**mydomain**.bundle

cat /usr/local/nginx/conf/letsencrypt/mydomain.crt
{"type": "urn:ietf:params:acme:error:rateLimited", "detail": "Service busy; retry later."}

Apache logs where it went down:

AH02561: Failed to configure certificate guntherneefs.be:443:0, check /usr/local/nginx/conf/letsencrypt/**mydomain**.crt
SSL Library Error: error:0909006C:PEM routines:get_name:no start line (Expecting: CERTIFICATE) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile?
SSL Library Error: error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib
AH00020: Configuration Failed, exiting

[githubRover]

As further background to this error the LE system was having problems. From history at https://letsencrypt.status.io/

November 11, 2022 05:21 UTC[Resolved] We have resolved the issue and traffic patterns have returned to normal.

November 11, 2022 02:32 UTC[Identified] We are aware of elevated http 503 error rates to our API endpoint in one of our datacenters. We have triaged the problem and the rates have decreased but continue to troubleshoot and monitor.

[timkimber]

@webservicebe Thanks for reporting this. I had a similar problem with one of my calls to LetsEncrypt, but fortunately that failed less catastrophically. I'll add a check for return status 503 to all of the curl checks to fix, and I'll also do the openssl final check you suggest as well

[webservicebe]

As I had the same problem this night I changed some things in getssl
getssl_verify_patch.txt

I didnot change added 503 to the action taken when you get a 500 from LE, because I don't see any use in hitting a webserver that is busy over and over again.
Maybe a fail and try another time is better in place?