Problems with SSL certificates

Hello,

I having the same problems as “moyo” user.

System

OS Ubuntu Linux 18.04.5 x86_64
Hestia Control Panel: v1.3.3

The installation was “clean”. After a few weeks of operation the following problem arises:

Unfortunately, several domains are affected by the problem. This is just an excerpt:

Can’t open /usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.de.crt for reading, No such file or directory
140239259701696:error:02001002:system library:fopen:No such file or directory:…/crypto/bio/bss_file.c:72:fopen(’/usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.de.crt’,‘r’)
140239259701696:error:2006D080:BIO routines:BIO_new_file:no such file:…/crypto/bio/bss_file.c:79:
unable to load certificate

Can’t open /usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.de.crt for reading, No such file or directory
139897576026560:error:02001002:system library:fopen:No such file or directory:…/crypto/bio/bss_file.c:72:fopen(’/usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.de.crt’,‘r’)
139897576026560:error:2006D080:BIO routines:BIO_new_file:no such file:…/crypto/bio/bss_file.c:79:
unable to load certificate

Can’t open /usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.net.crt for reading, No such file or directory
140167430660544:error:02001002:system library:fopen:No such file or directory:…/crypto/bio/bss_file.c:72:fopen(’/usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.net.crt’,‘r’)
140167430660544:error:2006D080:BIO routines:BIO_new_file:no such file:…/crypto/bio/bss_file.c:79:
unable to load certificate

Can’t open /usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.de.crt for reading, No such file or directory
140222121484736:error:02001002:system library:fopen:No such file or directory:…/crypto/bio/bss_file.c:72:fopen(’/usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.de.crt’,‘r’)
140222121484736:error:2006D080:BIO routines:BIO_new_file:no such file:…/crypto/bio/bss_file.c:79:
unable to load certificate

Best regards

Tom

Please do not bump topics older then 1 year.

According the error /usr/local/hestia/data/users/XXXXX/ssl/XXXXXXXXX.de.crt does not exsits what exactly have you done?

Please note we have identified some issue with certifacates in 1.3.5 and we have made some changes:

These will be released in 1.4 scheduled for this week for release.

Hello eris, I didn’t do anything. After a routine from Hestia had obviously run in the evening / at night, the certificates were deleted at that point.

Unfortunately this has not happened for the first time.

I can restore the certificates via a timeshift backup, but then either Apache or NGNIX does not start.

The attempt to recreate SSL for a domain fails either.

Message /tmp/tmp.iN3pjquREx '[Error 2]

Best regards

Tom

Can you check if you got any log for that time in /var/log/hestia starting with LE_?

Hello,

I’ll post a log later. I’m trying to find the right moment when the error occurs.

I am currently looking at the time machine backups to see what time this happens.

It always starts very simply:

Error: Let’s Encrypt validation status 400. Details: Unable to update challenge :: authorization must be pending

After a few days, the certificates will be deleted, as described in the first post.

But it cannot be the case that you have to regularly setup/rebuild a system again after 6-8 weeks.

New and imported domains are affected.

Best regards

Tom

After 8 weeks the system tries to recreate an ssl certificate… Normally these are 3 months valid.

Error: Let’s Encrypt validation status 400. Details: Unable to update challenge :: authorization must be pending

Points to an issue with Nginx or if you are using Cloudflare that an proxy is enabled it is very useful to have the logs.

Also you are currently running 1.3.3 so far now we have 1.3.5 released… So you are slightly behind the last update…

A rebuild is needed due to the lets encrypt cert update, as @eris already pointed out. This is how the system works, also you should have got a notification e-mail about the LE400 error while running v-update-letsencrypt-renew. But at the end; the cert should not get removed, it would only outdate - sounds like there is another issue.

I can’t post more than 2 links. Therefore the first part of the log is missing.
A complete LE log is available for each domain.

An example:

The last step.

==[Step 5]==

status: 400
nonce: 0103H9aZLpsXc4OVTxj7qmu5QCy2lNGZS0RdO8BanhL7LWs
validation:
details: Unable to update challenge :: authorization must be pending
answer: HTTP/2 400
server: nginx
date: Sat, 22 May 2021 01:47:58 GMT
content-type: application/problem+json
content-length: 144
boulder-requester: 17777143
cache-control: public, max-age=0, no-cache
link: https://acme-v02.api.letsencrypt.org/directory;rel=“index”
replay-nonce: 0103H9aZLpsXc4OVTxj7qmu5QCy2lNGZS0RdO8BanhL7LWs

{
“type”: “urn:ietf:params:acme:error:malformed”,
“detail”: “Unable to update challenge :: authorization must be pending”,
“status”: 400
}

==[Abort Step 5]==
=> Wrong status

Hello,

the certificates are definitely deleted. I can see that in the backups.

You also need the second last set it contains something like:
{
“type”: “http-01”,
“status”: “pending”,
"url": “https://acme-v02.api.letsencrypt.org/acme/chall-v3/12520447717/scDRXA”,
“token”: “9yriok5bpLtV__m-rZ8f2tQmrfeQli0tCxSj4iNkv2Y”
}

Follow this link and you will see some more info

“urn:ietf:params:acme:error:connection”
detail “Fetching https://www.xxxxxxxx.de/.well-known/acme-challenge/qxJjK8iIr80C-jzieTRJ3jUjpxZ_4h8fc5EzJhi7bZc: Timeout during connect (likely firewall problem)”
status 400

Sounds like a good thing to start searching :slight_smile:

The firewall has the default settings :wink:

2 screenshots. One shows the number of certificates from last night. The other the state of today at noon. So they have definitely been deleted. But not manually.

Sorry but we are not able to look into the server. Check out error.log and see what is happening. Also do you have IPv6 configiured?

No IPv6 is deactivated. No IPv6-records in DNS an no IPv6 in /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT=“nosplash nofb nomodeset ipv6.disable=1”
GRUB_CMDLINE_LINUX=“console=ttyS0,57600 console=tty0 net.ifnames=0 biosdevname=0 ipv6.disable=1”