Hi! I am running a https-webpage on my Debian 9 stretch armhf Raspbian Raspberry Pi 3B+ server and i wanted to use a Letsencrypt certificate for having a valid certificate. I generated a certificate including chain with letsencrypt and certbot, but when i loaded the page on my desktop chromium browser the certificate was rejected as invalid. It was listed as issued by rpiserver for rpiserver, no certificate chain was recognized. My apache2 is 2.4.25 and i even specified the chain file extra in my Virtualhost file generated by letsencrypt and certbot. I tried different options but always the same result: Chromium does not recognize a chain nor the domain for which the certificate was generated with certbot/letsencrypt. The certificate does not give the FQDN that was found for my domain by certbot/letsencrypt. I guess something goes wrong in the generation of the keys or certificates with the arguments.
what's your domain name? What command did you used? There is a template that makes things easier.
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
UPDATE: I have looked into the cert with openssl x509 and it is issued correctly with proper FQDN. It looks like my Linux Debian 9 stretch desktop Chromium has still stored an old self-signed certificate for my site and does not load the new certificate for some reason when i go on the site. Deleting the cache did not solve the problem. Looking through all authorities and certificates stored in Chromium via the Web interface, i did not find my self-signed certificate anymore, neither the Lets encrypt certificate authority or chain. Looks like Chromium has cached somewhere the old self-signed certificate and presents that instead of checking for the new certificate transmitted by my webserver.
It looks like Chromium has some problem loading the certificate into its certificate memory. First, it does not recognize the certificate authority from the certificate, then it has also problems storing the new certificate into its certificate memory. When one sees the security warning of Chromium in the address line, then an export of the certificate leads to an incorrect import into the certificate memory in sequence it seems.
Hi @ThomasKorimort,
I think your interpretations of the causes of the errors may be mistaken; could you please fill out the form that @JuergenAuer asked you to?
You haven’t shown the error nor filled out the questionnaire.
At this point, the only help we can give would be guessing…
So here is my guess: You didn’t use the fullchain.pem file.
I used openssl x509 command to read the contents of the certificate. It looks like the certificate is ok. Just Chromium seems to not like to integrate the certificate properly into its certificate memory. I guess taking the time to fill the form will not really improve my chances of getting some of your form processing engineers to investigate the issue with Chromium certificate memory or forward it to proper people?
Can this Chromium installation access other websites using Let’s Encrypt certificates, such as this one?
…without any problem it access this page and the certificate data looks like this:
SSL Server Certificate
Issued To
Common Name (CN)
http://community.letsencrypt.org
Organization (O)
<Not Part Of Certificate>
Organizational Unit (OU)
<Not Part Of Certificate>
Issued By
Common Name (CN)
Let’s Encrypt Authority X3
Organization (O)
Let’s Encrypt
Organizational Unit (OU)
<Not Part Of Certificate>
Some time ago i installed a self-signed certificate for my domain. It looks like this certificate is still used by Chromium though it does not appear anywhere in the certificate management web pages. Also Chromium does not seem to try to use the new certificate that is broadcasted by my webserver on accessing my domain. It seems to simply use the old certificate. Maybe it has cached my domain somewhere and does not check for new certificates for that domain as long as the old certificate is not expired or something similar!!! Complete clearing of cache via the web interface also did not solve the problem. Maybe that is a problem that should be discussed in the Chromium forums…
If you tell us the domain name, we can try our own tests with Chromium (and other tools) and see whether we agree with your analysis or whether it's a different kind of problem that we're already familiar with.
My domain name is “korimort.freedynamicdns.net” . It is a No-IP dynamic domain with public dynamic IP. Recently, No-IP has simply started to cancel it after one month without further notice. But i have confirmed it some one week ago. So, for at least some three weeks it should be up and running.
Your server apparently isn’t serving your Let’s Encrypt certificate, but instead a different self-signed certificate for rpiserver. In this case, there’s no browser bug, but rather a problem with how your server is configured.
How did you obtain your Let’s Encrypt certificate, and how did you configure your Raspberry Pi to use it after you obtained it?
As far as i remember i followed an instruction manual for setting up a https-connection for nextcloud-13 or nextcloud 14, but i don’t know the web page from which i took the information anymore. That instruction showed how to use certbot to install a VirtualHost in apache2 with SSL https encryption and it put also the directives for SSLCertificateFile aso. into the virtualhost conf, but already at that time the self-signed certificate was used. Some days ago i tried something and shot my apache2.4.25 web server so i had to reinstall it after purging its installation. Afterwards i upgraded to nextcloud 15.0.5 and followed the new instruction manual on the nextcloud webpage. That did not mention anymore letsencrypt/certbot procedure for https encryption. So i had to investigate myself how to enable https for my new nextcloud Virtualhost. I generated the certificate with certbot --apache command and it generated for my nexdcloud:80 virtualhost a nextcloud-le-ssl virtualhost with SSLCertificateFile, SSLCertificateChain,… inside it with what seemed to me proper assignment of fullchain and cert. There were only two such lines, but i added a third one, which aught to be only applicable for <= apache2-2.4.8 , but still i tried with my apache2-2.4.25
Options +FollowSymlinks AllowOverride All Satisfy Any Dav off
SetEnv HOME /var/www/nextcloud
SetEnv HTTP_HOME /var/www/nextcloud
RewriteCond %{SERVER_NAME} =korimort.freedynamicdns.net
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
ServerName korimort.freedynamicdns.net
SSLCertificateFile /etc/letsencrypt/live/korimort.freedynamicdns.net-0001/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/korimort.freedynamicdns.net-0001/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/korimort.freedynamicdns.net-0001/chain.pem
Include /etc/letsencrypt/options-ssl-apache.conf
<Directory /var/www/nextcloud/>
Options +FollowSymlinks
AllowOverride All
Satisfy Any
SetEnv HOME /var/www/nextcloud
SetEnv HTTP_HOME /var/www/nextcloud
RewriteCond %{SERVER_NAME} =korimort.freedynamicdns.net
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
If really the old self-signed certificate is served then how can this happen after a purge of the complete apache2 install? There are only two sites enabled on my webserver: nextcloud and nextcloud-le-ssl plus default and default_ssl
Maybe try grep -r SSLCertificate /etc/apache2?
Loooks like your default is used.
What says
apachectl -D DUMP_VHOSTS
$ apachectl -D DUMP_VHOSTS
AH00526: Syntax error on line 33 of /etc/apache2/sites-enabled/default-ssl.conf:
SSLCertificateKeyFile: file ‘/etc/ssl/private/ssl-cert-snakeoil.key’ does not exist or is empty
Action ‘-D DUMP_VHOSTS’ failed.
The Apache error log may have more information.
the default-ssl.conf file has only two lines with SSL*:
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
That file was completely automatically treated by certbot/letsencrypt as far as i remember. Certbot only found the korimort.freedynamicdns.net domain for providing site certificates. The snakeoil certificates maybe got deleted when i purged the apache installation???
Then remove that vHost if you don’t use it.
Ok. I removed default-ssl vhost. Now apachectl -D VHOSTS_DUMP says
apachectl -D DUMP_VHOSTS
VirtualHost configuration:
178.112.124.21:443 korimort.freedynamicdns.net (/etc/apache2/sites-enabled/nextcloud-le-ssl.conf:2)
178.112.124.21:80 is a NameVirtualHost
default server 178.112.124.21.wireless.dyn.drei.com (/etc/apache2/sites-enabled/nextcloud-le-ssl.conf:31)
port 80 namevhost 178.112.124.21.wireless.dyn.drei.com (/etc/apache2/sites-enabled/nextcloud-le-ssl.conf:31)
port 80 namevhost 178.112.124.21.wireless.dyn.drei.com (/etc/apache2/sites-enabled/nextcloud.conf:4)
*:80 korimort.freedynamicdns.net (/etc/apache2/sites-enabled/000-default.conf:1)
Now you have a Grade Q - http over Port 443 ( https://check-your-website.server-daten.de/?q=korimort.freedynamicdns.net ):
| Domainname | Http-Status | redirect | Sec. | G |
|---|---|---|---|---|
| • http://korimort.freedynamicdns.net/ | ||||
| 178.112.124.21 | 200 | 0.140 | H | |
| • https://korimort.freedynamicdns.net/ | ||||
| 178.112.124.21 | -4 | 0.250 | W | |
| SendFailure - The underlying connection was closed: An unexpected error occurred on a send. The handshake failed due to an unexpected packet format. | ||||
| • http://korimort.freedynamicdns.net:443/ | ||||
| 178.112.124.21 | 200 | 0.130 | Q |
So your port 443 / korimort ... doesn't have a SSL-definition.
So the content of
may be wrong or incomplete.
PS: Personally, I would remove default server definitions. Because they may be used instead of the named vHosts if something is wrong.
And a port 80 definition in a SSL file
is curious.
| Host | T | IP-Address | is auth. | ∑ Queries | ∑ Timeout | |
|---|---|---|---|---|---|---|
| — | — | — | — | — | — | |
| korimort.freedynamicdns.net | A | 178.112.124.21 | yes | 1 | 0 | |
| AAAA | yes | |||||
| www.korimort.freedynamicdns.net | Name Error | yes | 1 | 0 | ||
| Zone (*) | DNSSEC - Informations (beta) | |||||
| — | — | |||||
| (root) | 1 DS RR published | |||||
| • Status: Valide because published | ||||||
| 3 DNSKEY RR found | ||||||
| Public Key with Algorithm 8, KeyTag 16749, Flags 256 | ||||||
| Public Key with Algorithm 8, KeyTag 19164, Flags 385 | ||||||
| Public Key with Algorithm 8, KeyTag 20326, Flags 257 (SEP = Secure Entry Point) | ||||||
| 2 RRSIG RR to validate DNSKEY RR found | ||||||
| • Algorithm: 8, 0 Labels, original TTL: 172800 sec, Signature-expiration: 23.03.2019, 00:00:00, Signature-Inception: 02.03.2019, 00:00:00, KeyTag 19164, Signer-Name: (root) | ||||||
| • Algorithm: 8, 0 Labels, original TTL: 172800 sec, Signature-expiration: 23.03.2019, 00:00:00, Signature-Inception: 02.03.2019, 00:00:00, KeyTag 20326, Signer-Name: (root) | ||||||
| • Status: Good - Algorithmus 8 and DNSKEY with KeyTag 19164 used to validate the DNSKEY RRSet | ||||||
| • Status: Good - Algorithmus 8 and DNSKEY with KeyTag 20326 used to validate the DNSKEY RRSet | ||||||
| • Status: Valide Chain of trust. Parent-DS with Algorithm 8, KeyTag 20326, DigestType 2 and Digest “4G1EuAuPHTmpXAsNfGXQhFjogECbvGg0VxBCN8f47I0=” validates local Key with the same values, Key ist Secure Entry Point (SEP) of the zone | ||||||
| net | 1 DS RR in the parent zone found | |||||
| 1 RRSIG RR to validate DS RR found | ||||||
| Algorithm: 8, 1 Labels, original TTL: 86400 sec, Signature-expiration: 17.03.2019, 05:00:00, Signature-Inception: 04.03.2019, 04:00:00, KeyTag 16749, Signer-Name: (root) | ||||||
| • Status: Good - Algorithmus 8 and DNSKEY with KeyTag 16749 used to validate the DS RRSet in the parent zone | ||||||
| 2 DNSKEY RR found | ||||||
| Public Key with Algorithm 8, KeyTag 35886, Flags 257 (SEP = Secure Entry Point) | ||||||
| Public Key with Algorithm 8, KeyTag 51638, Flags 256 | ||||||
| 1 RRSIG RR to validate DNSKEY RR found | ||||||
| • Algorithm: 8, 1 Labels, original TTL: 86400 sec, Signature-expiration: 16.03.2019, 16:38:57, Signature-Inception: 01.03.2019, 16:33:57, KeyTag 35886, Signer-Name: net | ||||||
| • Status: Good - Algorithmus 8 and DNSKEY with KeyTag 35886 used to validate the DNSKEY RRSet | ||||||
| • Status: Valide Chain of trust. Parent-DS with Algorithm 8, KeyTag 35886, DigestType 2 and Digest “eGKyf19Rbr4ZaARE1M5edimBkxhCxGXwAjZAHYvZc+4=” validates local Key with the same values, Key ist Secure Entry Point (SEP) of the zone | ||||||
| freedynamicdns.net | 0 DS RR in the parent zone found | |||||
| DS-Query in the parent zone has a valide NSEC3 RR as result with the hashed domain name between the hashed NSEC3-owner and the hashed NextOwner. So the parent zone confirmes the non-existence of a DS RR. | ||||||
| 0 DNSKEY RR found | ||||||
| korimort.freedynamicdns.net | 0 DS RR in the parent zone found | |||||
| 0 DNSKEY RR found | ||||||
| www.korimort.freedynamicdns.net | 0 DS RR in the parent zone found | Domain Nameserver NS-IP |
www.korimort.freedynamicdns.net • nf1.no-ip.com
korimort.freedynamicdns.net • nf1.no-ip.com / f2.fra.hv.as29997.net 194.62.182.53 •
• 2a07:dc00:1820::53 •
freedynamicdns.net • nf1.no-ip.com / f2.fra.hv.as29997.net •
• nf2.no-ip.com / f1.ams.hv.as29997.net •
• nf3.no-ip.com / f1.ams.vr.as29997.net •
• nf4.no-ip.com / f2.ams.vr.as29997.net •
net • a.gtld-servers.net •
• b.gtld-servers.net •
• c.gtld-servers.net •
• d.gtld-servers.net •
• e.gtld-servers.net •
• f.gtld-servers.net •
• g.gtld-servers.net •
• h.gtld-servers.net •
• i.gtld-servers.net •
• j.gtld-servers.net •
• k.gtld-servers.net •
• l.gtld-servers.net •
• m.gtld-servers.net •
SOA - records (beta)
Domain: net
Primary: a.gtld-servers.net
Mail: nstld.verisign-grs.com
Serial: 1551707396
Refresh: 1800
Retry: 900
Expire: 604800
TTL: 86400
num Entries: 11
Domain: net
Primary: a.gtld-servers.net
Mail: nstld.verisign-grs.com
Serial: 1551707411
Refresh: 1800
Retry: 900
Expire: 604800
TTL: 86400
num Entries: 1
Domain: net
Primary: a.gtld-servers.net
Mail: nstld.verisign-grs.com
Serial: 1551707381
Refresh: 1800
Retry: 900
Expire: 604800
TTL: 86400
num Entries: 1
Domain: net
Primary: a.gtld-servers.net
Mail: nstld.verisign-grs.com
Serial: 1551707411
Refresh: 1800
Retry: 900
Expire: 604800
TTL: 86400
num Entries: 1|