Inaccessible website in spide of correctly issued certificates

Help
1

My domain is:

signexpert.sk

I ran this command:

certbot --apache --expand --agree-tos --no-eff-email --redirect --hsts --email peter@draxler.ml -d signexpert.sk -d signexpert.cz -d signexpert.hu -d signexpert.eu

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/signexpert.sk.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/vhost-signexpert.sk-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/vhost-signexpert.cz-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/vhost-signexpert.hu-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/vhost-signexpert.eu-le-ssl.conf
Enhancement Strict-Transport-Security was already set.
Enhancement Strict-Transport-Security was already set.
Enhancement Strict-Transport-Security was already set.
Enhancement Strict-Transport-Security was already set.
Enhancement redirect was already set.
Enhancement redirect was already set.
Enhancement redirect was already set.
Enhancement redirect was already set.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Your existing certificate has been successfully renewed, and the new certificate
has been installed.

The new certificate covers the following domains: https://signexpert.sk,
https://signexpert.cz, https://signexpert.hu, and https://signexpert.eu

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=signexpert.sk
https://www.ssllabs.com/ssltest/analyze.html?d=signexpert.cz
https://www.ssllabs.com/ssltest/analyze.html?d=signexpert.hu
https://www.ssllabs.com/ssltest/analyze.html?d=signexpert.eu
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/signexpert.sk/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/signexpert.sk/privkey.pem
   Your cert will expire on 2020-06-27. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

My web server is (include version):

Server version: Apache/2.4.38 (Debian)
Server built: 2019-10-15T19:53:42

The operating system my web server runs on is (include version):

Debian GNU/Linux 10.3
I'm using Docker image based on php:7.4-apache

I can login to a root shell on my machine (yes or no, or I don't know):

yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot 0.31.0

Everything went through fine. However, when I access my website from Chrome or Edge, I get a nasty error message:

Your connection is not private

Attackers might be trying to steal your information from signexpert.sk (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Is there anything that can be done to fix this? Will this get fixed by itself? Can anything be done to speed up the resolution? My website is not accessible for customers :cry:.

Thanks for any help.

2

I see your website just fine: https://signexpert.sk/

if you are trying to use https://www.signexpert.sk/ this is expected, you need a certificate for both names. add

-d www.signexpert.sk -d www.signexpert.cz -d www.signexpert.hu -d www.signexpert.eu

to your certbot command. (you should redirect one to the other.)

3

It seems like this issue is resolved now. It did get fixed by itself. The website was unaccessible at https://signexpert.sk for about 30 minutes from Google Chrome and Chromium based Edge. Safari on my phone worked okay.

I’d still like to understand how this happend. I think I only changed the location of certificate files on my server. Successful issuing of new certificates also did not fix the issue. This domain has run on this server on Let’s Encrpyt’s certifiactes for about a month.

4

this is why it's not complaining about the missing www (you should still add it or firefox users will not be able to use www.signexpert.sk)

and this is why chrome complained. certificate transparency logs are not instant. you should enable OCSP stapling. Add the --ocsp-staple option to your certbot command too.

5

@9peppe I don’t think Let’s Encrypt embeds SCTs in the OCSP replies, only in the certificates themselves.

6

I don’t actually know. So… why did chrome decide to raise this error?

7

I’m not sure why it was there earlier, but is gone now.

I do know the cert has a Let’s Encrypt Oak CT SCT. And that CT is recognised since Chrome version 78.

So if a certificate has just 2 SCT’s with one from Google and one from Let’s Encrypt and Chrome is too old (i.e. <78), I think Chrome would reject the cert, because it has less than the required SCTs (two from two different companies).

Although like I said, if that was the case, the error should have persisted.

8

Hi @PeterDraex

there are some users with the same problem.

Looks like sometimes Chrome doesn't see the too new CT entry.

I use my own client with a split - first, the certificates are created. Some hours later, they are installed.

May be a workaround (if you use Certbot):

Create the new certificate with certonly.

One hour later, restart your webserver.

9

@JuergenAuer Does Chrome “call out” to the certificate log to verify its entry? :face_with_raised_eyebrow: I thought the signature in the embedded SCT was enough: it’s signed by the logs private key and the public key of the log is known. It shouldn’t be necessary to “check for the new CT entry”.

10

@Osiris @9peppe
I'll add the www.signexpert.sk, thanks for the suggestion. Btw, what exactly does Chrome do? Why does it work in Chrome?

So what does --ocsp-staple do? It denotes support for OCSP in the certificate, which forces the browser to check validity of the certificate with Let's Encrypt?

I'm using Chrome 80 and don't think that my version has changed in the past hours. The problem must be elsewhere.

@JuergenAuer: Chrome doesn’t see the too new CT entry

Could this perhaps be reported to Chrome as a bug?

11

It accepts a certificate for www.example.com even if it's only valid for example.com

It configures the server to send a stapled ocsp response.

12

May be. I don't know how that works. But sometimes this problem is reported.

New certificate, Chrome doesn't accept it. Some minutes later - all is ok.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.