Can't renew certificate since TLS-SNI-01 end-of-life

Hello community experts,

I would appreciate your assistance in renewing my certificate which expired due to TLS-SNI-01 end-of-life and me being unable to renew since. Before everything worked fine including automatic updates.
I followed quite a few of the recommended guidelines, but always got stuck somewhere back in Feb/March, so I would like to start over from scratch with your assistance in fixing the problem.

My domain is:
maier.dyn.cc
It runs a Nextcloud (NC) with version 16.0.1 and formerly strict https.

I ran this command:

certbot --apache renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/maier.dyn.cc.conf


Cert is due for renewal, auto-renewing…
Error while running apachectl -v.

apachectl: The “-v” option is not supported.

Could not choose appropriate plugin: The apache plugin is not working; there may be problems with your existing configuration.
The error was: PluginError(“Unable to run [‘apachectl’, ‘-v’] -v”)
Attempting to renew cert (maier.dyn.cc) from /etc/letsencrypt/renewal/maier.dyn.cc.conf produced an unexpected error: The apache plugin is not working; there may be problems with your existing configuration.
The error was: PluginError(“Unable to run [‘apachectl’, ‘-v’] -v”). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/maier.dyn.cc/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/maier.dyn.cc/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)
[root@wi user]#

My web server is (include version):

# httpd -v
Server version: Apache/2.4.39 (Fedora)
Server built:   Apr 17 2019 08:55:27
$ php -v
PHP 7.2.18 (cli) (built: Apr 30 2019 08:49:02) ( NTS )
Zend Engine v3.2.0

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

$ cat /etc/fedora-release
Fedora release 29 (Twenty Nine) incl. latest updates

My hosting provider, if applicable, is:
NR: DynDns to my home router

I can login to a root shell on my machine:
Yes

I’m using a control panel to manage my site:
No

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

$ certbot --version
certbot 0.31.0

try update your certbot

1 Like

Thanks for your great hint to on the update! Learning on dnf features :slight_smile:
The update mainly worked, except something minor which I would consider not important for updating certbot.

Details here on fedora update problem

I executed

sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2019-2361aca4af

and it work for the most part, except for some error which I would consider not important for updating certbot.
Fehlgeschlagen:
python2-configobj-5.0.6-14.fc29.noarch

Fehler: Transaktion fehlgeschlagen

Unfortunately now the second underlaying problem shows up when trying to update the certificate:

Status now is:

$ certbot --version
certbot 0.34.2

I ran this command:

certbot --apache renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/maier.dyn.cc.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for maier.dyn.cc
Waiting for verification…
Challenge failed for domain maier.dyn.cc
http-01 challenge for maier.dyn.cc
Cleaning up challenges
Attempting to renew cert (maier.dyn.cc) from /etc/letsencrypt/renewal/maier.dyn.cc.conf produced an unexpected error: Some challenges have failed… Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/maier.dyn.cc/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/maier.dyn.cc/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: maier.dyn.cc
    Type: connection
    Detail: Fetching
    http://maier.dyn.cc/.well-known/acme-challenge/sssLDP-aCoX-NiKSFM9XIMG_Sqrf8A3xu8-lUTJ5GKM:
    Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

Any hint on what to do / check next would be great.

Hi @fedoriger

your http port 80 doesn't answer ( https://check-your-website.server-daten.de/?q=maier.dyn.cc ):

Domainname Http-Status redirect Sec. G
• http://maier.dyn.cc/
84.138.97.229 -14 10.027 T
Timeout - The operation has timed out
• http://www.maier.dyn.cc/
84.138.97.229 -14 10.027 T
Timeout - The operation has timed out
• https://maier.dyn.cc/
84.138.97.229 302 https://maier.dyn.cc/login 0.697 N
Certificate error: RemoteCertificateChainErrors
• https://www.maier.dyn.cc/
84.138.97.229 400 0.450 N
Bad Request
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
• https://maier.dyn.cc/login 200 0.390 N
Certificate error: RemoteCertificateChainErrors
• http://maier.dyn.cc/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
84.138.97.229 -14 10.033 T
Timeout - The operation has timed out
Visible Content:
• http://www.maier.dyn.cc/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
84.138.97.229 -14 10.030 T
Timeout - The operation has timed out

That's required if you want to use http-01 validation.

You have some older certificates, first from 2017-06-09 04:48:00, last from 2018-11-18 23:10:33, that' expired and installed.

Looks like you have used tls-sni-01 validation (via port 443), that's not longer supported. So you have to switch to another validation method.

http-01 validation requires an open and answering port 80.

1 Like

Attempting to connect to http://maier.dyn.cc/ results in a “No route to host” error.

Maybe there’s a firewall or port forwarding problem?

1 Like

Hello Juergen, Matt,

that's right, I used tls-sni-01 validation (via port 443) in the past.

That's what I would like to do, but I don't know how :frowning:

What I checked already is that port 80 is open and forwards to my Nextcloud server's local IP as it does for port 443.

In the very beginning of setting up Nextcloud port 80 was open to the public, but this is gone since I followed some recommendations by Nextcloud to use strict https only and chose the setting former letsencrypt offered to use https (only?) as well. This was fine up to now.

If you would be so kind to help me configure the virtual hosts (something I have an extremly rough understanding of only) or whatever is necessary to get rid of the problem that port 80 is not answering:

Which info shall I provide?

Then do that again. "Strict https" - I don't understand that. You can use a redirect http -> https. But http-01 validation requires an open port 80.

I don't use nextcloud. But your answer says: "There is a solution".

You are right: There is a solution, which might be of interest for all Fedora (and maybe also CentOS/Archlinux/RedHat) users:
I needed to open the http port 80 in the Fedora default firewall - Up to now I did not even know that such a firewall existed.

Here:

you can read that the following commands are necessary to check the status, open the http port and restart the firewall to make the changes effective:

# firewall-cmd --get-active-zones
  public
    interfaces: eno1
# firewall-cmd --permanent --zone=public --add-service=http
  success
# systemctl restart firewalld.service

Knowing the reason I have to correct myselves partially: Port 80 was never before open to the public due to the Fedora firewall. It was open in the router only, which is not sufficient. Addressing my server via http worked anyhow within my network, because there is no need to "cross" the firewall and I messed that up.

cerbot --apache

then worked like a charm:

Certificate renewal
# certbot --apache                           
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: maier.dyn.cc
2: www.maier.dyn.cc
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1,2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/maier.dyn.cc.conf)

It contains these names: maier.dyn.cc

You requested these names for the new certificate: maier.dyn.cc,
www.maier.dyn.cc.

Do you want to expand and replace this existing certificate with the new
certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: E
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for maier.dyn.cc
http-01 challenge for www.maier.dyn.cc
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/httpd/conf.d/http-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf.d/http-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf.d/http-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting vhost in /etc/httpd/conf.d/http.conf to ssl vhost in /etc/httpd/conf.d/http-le-ssl.conf

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

The new certificate covers the following domains: https://maier.dyn.cc and
https://www.maier.dyn.cc

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=maier.dyn.cc
https://www.ssllabs.com/ssltest/analyze.html?d=www.maier.dyn.cc
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/maier.dyn.cc/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/maier.dyn.cc/privkey.pem
   Your cert will expire on 2019-09-06. 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
# 

Main problem solved and I am really happy to have a working certificate again! :smiley:

I would appreciate if you could assist with some hints on the following problems that now face the daylight: Still I get a grade "C" when testing my website again:

1. Errors

C Error - more then one version with Http-Status 200
C Error - no preferred version www or non-www

(I suppose it should be than instead of then in the error message, just in case you care.)
How to fix these errors?
The second error appears strange to me, as http is rewritten to https for both, maier.dyn.cc as well as www.maier.dyn.cc.
I had to adapt the VirtualHost setup updated/created by Letsencrypt.
The current setup is

httpd.conf
ServerRoot "/etc/httpd"
Listen 80
Include conf.modules.d/*.conf
User apache
Group apache
ServerAdmin post@xx.de
ServerName maier.dyn.cc
<Directory />
    AllowOverride none
    Require all denied
</Directory>
<Directory "/var/www">
    AllowOverride None
    Require all granted
</Directory>
<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>
<IfModule dir_module>
    DirectoryIndex index.html
</IfModule>
AccessFileName .htaccess
<Files ".ht*">
    Require all denied
</Files>
ErrorLog "logs/error_log"
LogLevel warn
<IfModule log_config_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
    <IfModule logio_module>
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>
    CustomLog "logs/access_log" combined
</IfModule>
<IfModule alias_module>
    ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
</IfModule>
<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Require all granted
</Directory>
<IfModule mime_module>
    TypesConfig /etc/mime.types
    AddType application/x-compress .Z
    AddType application/x-gzip .gz .tgz
    AddType text/html .shtml
    AddOutputFilter INCLUDES .shtml
</IfModule>
AddDefaultCharset UTF-8
<IfModule mime_magic_module>
    MIMEMagicFile conf/magic
</IfModule>
EnableSendfile on
IncludeOptional conf.d/*.conf
http_rewrite.conf
<VirtualHost *:80>
  ServerAdmin post@xx.de
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =maier.dyn.cc [OR]
  RewriteCond %{SERVER_NAME} =www.maier.dyn.cc
  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] 
  ErrorLog logs/http_error_log
  CustomLog logs/http_access_log combined
</VirtualHost>
ssl.conf
Listen 443 https
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
<VirtualHost _default_:443>
  ServerAdmin post@xx.de
  DocumentRoot "/var/www/nextcloud/"
  ServerName maier.dyn.cc
  ServerAlias www.maier.dyn.cc
  ErrorLog logs/ssl_error_log
  TransferLog logs/ssl_access_log
  LogLevel warn
  SSLEngine on
  SSLProtocol all -SSLv3
  SSLProxyProtocol all -SSLv3
  SSLHonorCipherOrder on
  SSLCipherSuite PROFILE=SYSTEM
  SSLProxyCipherSuite PROFILE=SYSTEM
  <FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
  </FilesMatch>
  <Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
  </Directory>
  BrowserMatch "MSIE [2-5]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
  CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
  Include /etc/letsencrypt/options-ssl-apache.conf
  SSLCertificateFile /etc/letsencrypt/live/maier.dyn.cc/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/maier.dyn.cc/privkey.pem
  <IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  </IfModule>
</VirtualHost>

2. Warnings

_acme-challenge.maier.dyn.cc missing entry or wrong length 1 0
_acme-challenge.www.maier.dyn.cc missing entry or wrong length 1 0
_acme-challenge.maier.dyn.cc.dyn.cc perhaps wrong 1 0
_acme-challenge.maier.dyn.cc.maier.dyn.cc perhaps wrong 1 0
_acme-challenge.www.maier.dyn.cc.maier.dyn.cc perhaps wrong 1 0
_acme-challenge.www.maier.dyn.cc.www.maier.dyn.cc perhaps wrong 1 0

3. Uncertainties: Lots of expired certificates
Does it make sense to remove the (many) expired certificates? Why?
Is there sort of a cleanup function that does the job?

(Expired) Certificates

Source crt.sh - old and new certificates, sometimes very slow.

Issuer last 7 days active num Certs
CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US 1 1 13

CRT-Id Issuer not before not after Domain names LE-Duplicate next LE
1555995761 CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US 2019-06-08 16:26:16 2019-09-06 16:26:16 maier.dyn.cc, www.maier.dyn.cc
2 entries duplicate nr. 1
957619905 CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US 2018-11-18 23:10:33 2019-02-16 23:10:33 maier.dyn.cc
1 entries
849448725 CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US 2018-09-19 20:21:42 2018-12-18 21:21:42 maier.dyn.cc
1 entries

[...many more]

1 Like

Happy to read that you have a new certificate.

Reading your last check - https://check-your-website.server-daten.de/?q=maier.dyn.cc

That's the same problem. You have a non-www and a www version. But both answers with a http status 200. Select one version as preferred version and add a redirect https + not-preferred version -> preferred version.

Your redirects http -> https are good -> Grade A. It's a problem that you have two https with status 200. One should have a redirect to the other.

You can ignore it. If you don't have defined such a domain name, the name server should send a "Name does not exist". Compare it with my own domain - https://check-your-website.server-daten.de/?q=server-daten.de#txt

_acme-challenge.www.server-daten.de
Name Error - The domain name does not exist

So it's a problem of your name server, but you can't fix it

That's normal. CT logs are append only logs, so nobody can remove old certificates.

I just fixed that, adding

# Redirect https://www.maier.dyn.cc auf https://maier.dyn.cc 
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.maier.dyn.cc
RewriteRule ^ https://maier.dyn.cc%{REQUEST_URI} [END,NE,R=permanent]

to ssl.conf after

ServerAlias www.maier.dyn.cc

Exactly. The redirect solved both errors. Now the overall grade is A and I'm happy.

I had to get into Apache *.conf (the surface only I have to admit) by self-studies of
https://httpd.apache.org/docs/2.4/de/
which took me about a day to understand the VirtualHost concepts, but found it to be well understandable and compact for my needs. Still the key is to have someone to pinpoint the core problems, so:

Thanks again for excellent support: @JuergenAuer & @mnordhoff

1 Like

Yep, now your site has a Grade A, that's very good.

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