You may be better off by deleting it.
2 Likes
Using a "--deploy-hook" may be a better choice.
3 Likes
Something else is wrong then because you are still using an older cert (see link here)
What does this show?
sudo apache2ctl -t -D DUMP_VHOSTS
No, that is not a good method. We need to redo your cert profile to use the --deploy-hook. This will only reload Apache when you actually get a fresh cert. Your method would reload every time the renew checks which is often
4 Likes
Yes, I have already done it.
Where can I see on the website that I am using an old certificate? I just noticed that I can't currently reach the server at all. I will drive to the location where the server is located tomorrow and check.
I will do that tomorrow.
Okay, how should I do it?
certbot renew --cert-name www.xn--derwscheladen-efb.at-0001 --deploy-hook 'apache2ctl graceful'
That should teach certbot to use that deploy hook for all renewals of that cert.
So, do that for each cert.
You can then check the renewal config file for the added deploy hook information.
4 Likes
Ah, I didn't see it yesterday because the server already had the issue at that time. I see it now as well.
So, should I set up a crontab to run this command every day?
No, it would only need to run once.
2 Likes
It is not. You can check yourself with a site like this SSL Checker
What does this command show?
apache2ctl graceful
Does it need sudo?
sudo apache2ctl graceful
2 Likes
Does it reload Apache or not? And does it produce no output?:
That command does not produce output when it works.
Can you show the contents of below conf file? And, is it possible for you to copy/paste to this forum instead of images? Images are much harder to work with
If you copy/paste please add 3 backticks before and after the output like this:
```
contents of conf file
```
3 Likes
More than likely, the problem has something to do with:
What shows?:
certbot certificates
2 Likes
I think most likely the Apache VirtualHost is still pointing to the original cert and not the -0001 one. The original renewal file was deleted by hand because it was empty but I think the old /live/ folders are probably still there and is what Apache is using.
We will know for sure once they show us the Apache VirtualHost
2 Likes
agreed
Which is where I was headed.
Two certs obviously exist [somewhere in that system].
grep -R letsencrypt /etc/apache2/
2 Likes
Yes, but we know from post #27 they have a valid cert as -0001 which is what we want them using. It's the only one remaining that is renewable.
They are using webroot so we need to get the VirtualHost changed manually to point to this "new" one
2 Likes
That doesn't discount my claim:
You just read it as the -0001 was the problem.
The -0001 is merely an indication of a problem.
When the -0001 was created, the problem began.
2 Likes
Okay, yes, I can do that, but there may be special characters not displayed correctly due to copying.
<IfModule mod_ssl.c>
<VirtualHost _default_:80>
ServerName www.derwäscheladen.at
Redirect permanent / https://www.xn--derwscheladen-efb.at/
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.derwäscheladen.at
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost _default_:443>
ServerAdmin xxnicoplxx@gmail.com
ServerName www.derwäscheladen.at
ServerName www.xn--derwscheladen-efb.at
# Set the directory from which httpd will serve files:
DocumentRoot /var/www/derwaescheladen.at
# As of version 2.4.17, Apache supports HTTP/2 (in addition to HTTP/1.0/1.1).
<IfModule http2_module>
Protocols h2 http/1.1
# If set to on (the default), the client ordering does not matter
# and only the ordering in the server settings influences the outcome
# of the protocol negotiation.
ProtocolsHonorOrder On
# Direct communication means that if the first bytes received by
# the server on a connection match the HTTP/2 preamble, the HTTP/2
# protocol is switched to immediately without further negotiation.
# This mode is defined in RFC 7540 for the cleartext (h2c) case.
# Its use on TLS connections not mandated by the standard.
H2Direct on
# Toggle the security checks on HTTP/2 connections in HTTPS. The se=
# curity checks require that the TSL protocol is at least TLSv1.2 and
# that none of the ciphers listed in RFC 7540, Appendix A is used.
H2ModernTLSOnly on
</IfModule>
<IfModule !http2_module>
Protocols http/1.1
</IfModule>
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/waescheladen-error.log
CustomLog ${APACHE_LOG_DIR}/waescheladen-access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/letsencrypt/live/www.xn--derwscheladen-efb.at/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.xn--derwscheladen-efb.at/privkey.pem
#Include /etc/letsencrypt/options-ssl-apache.conf
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# If a URL which maps to a directory is requested and there is no DirectoryIndex
# (e.g., index.html) in that directory, then mod_autoindex will return a formatted
# listing of the directory. With ‘-Indexes’ this results in an “You don't have
# permission to access "Directory" on this server.†error message instead. Also,
# this server will follow symbolic links. (This is the default setting.)
<Directory /var/www/derwäscheladen.at>
Options -Indexes +FollowSymLinks
AllowOverride All
#Order Deny,Allow
#Deny from All
Order Allow,Deny
Allow from All
# Allow access from the internet?
#Allow from 10.114.57.0/24
ErrorDocument 403 "<br/>"
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
# BrowserMatch "MSIE [2-6]" \
# nokeepalive ssl-unclean-shutdown \
# downgrade-1.0 force-response-1.0
# SSL2 and SSL3 as well as all TLSv1.0 and TLSv1.1 ciphers should be
# regarded as obsolete and insecure.
SSLProtocol -ALL +TLSv1.2 +TLSv1.3
# Deactivate the session cache and the tickets. Using them without
# restarting the web server with an appropriate frequency (e.g. daily)
# compromises PFS (“perfect forward secrecyâ€).
SSLSessionTickets off
# Prevent insecure renegotiations.
SSLInsecureRenegotiation off
# Enabling compression causes security issues in most setups (the so
# called CRIME – Compression Ratio Info-Leak Made Easy – attack).
SSLCompression off
# The server selects the cipher suite, not the clients. This instructs
# Apache to select the best possible ciphersuite during TLS handshake
# (instead of leaving it to the client to make that choice).
SSLHonorCipherOrder on
# This cipher suite configuration uses only suites that provide forward
# secrecy, in the order that provides the best performance.
# Generate strong Diffie–Hellman parameters:
# sudo openssl dhparam -out /etc/ssl/certs/www.derwäscheladen.at-dhparams.pem 4096
# → P = public (prime) modulus (4096 bit) + G = public (prime) base (= 2)
#SSLOpenSSLConfCmd DHParameters /etc/ssl/certs/www.derwäscheladen.at-dhparams.pem
# Preferred Elliptic Curve, c.f. https://poly.apachehaus.de/ssl-config.php
SSLOpenSSLConfCmd ECDHParameters X448
# Other accepted Elliptic Curves:
SSLOpenSSLConfCmd Curves X448:X25519:secp384r1:secp256r1
# These secure suites are used up to TLS1.2:
# C.f. https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29
SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256 \
ECDHE-RSA-AES128-GCM-SHA256 \
ECDHE-ECDSA-AES256-GCM-SHA384 \
ECDHE-RSA-AES256-GCM-SHA384 \
ECDHE-ECDSA-CHACHA20-POLY1305 \
ECDHE-RSA-CHACHA20-POLY1305 \
DHE-RSA-AES128-GCM-SHA256 \
DHE-RSA-AES256-GCM-SHA384"
# These suites are used for TLS1.3 only:
SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
# Add security and privacy related headers, c.f. https://lars.timmann.de/wiki/index.php/Apache
<IfModule mod_headers.c>
# Cookie HTTP header flag with ‘HTTPOnly & Secure’ to protect a
# website from XSS attacks:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
# HSTS informs browsers that the site should only be accessed using
# HTTPS, and that any future attempts to access it using HTTP should
# automatically be converted to HTTPS:
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
# X-Frame-Options with SAMEORIGIN specifies, that pages can be used
# in a frame as long as the site including it in a frame is the same
# as the one serving the page:
Header always set X-Frame-Options SAMEORIGIN
# Block requests if the request destination is of type style and the
# MIME type is not text/css, or of type script and the MIME type is
# not a JavaScript MIME type:
Header always set X-Content-Type-Options nosniff
# If you do not need to support legacy browsers, it is recommended
# that you use Content-Security-Policy without allowing unsafe-inline
# scripts instead:
#Header set X-XSS-Protection "1; mode=block"
# Content Security Policy (CSP) für WordPress:
# https://epiph.yt/blog/2017/content-security-policy-fuer-wordpress/
# Content Security Policy Reference: https://content-security-policy.com/
#Header set Content-Security-Policy "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self' wss://kittpress.com; child-src 'self' *.google.com http://www.facebook.com platform.twitter.com *.youtube.com;"
# Do not show this page, media, or resource in search results. Do not
# follow the links on this page, i.e. don't use the links on the page
# to discover linked pages:
Header set X-Robots-Tag "noindex, nofollow"
# SetEnv variables can later be queried in PHP code:
SetEnv modHeadersAvailable true
</IfModule>
</VirtualHost>
# AH00526: SSLSessionCache cannot occur within <VirtualHost> section
# The SSL Session Cache is an optional facility that speeds up parallel request
# processing. SSL session information, which are processed in requests to the same
# server process (via HTTP keepalive), are cached locally. But because modern clients
# request inlined images and other data via parallel requests (up to four parallel
# requests are common), those requests are served by different preforked server
# processes. Here an interprocess cache helps to avoid unnecessary session handshakes.
#SSLSessionCache shmcb:/opt/apache2/logs/ssl_gcache_data(512000)
SSLSessionCache none
# AH00526: SSLStaplingCache cannot occur within <VirtualHost> section
# OCSP stapling allows a web server to obtain a digitally signed and time-stamped
# OCSP response from the OCSP responder operated by the CA that issued the server
# certificate. The responder gives a ‘valid’ or ‘revoked’ status to the web browser,
# communicating to the browser about the validity status of the SSL certificate.
SSLUseStapling On
SSLStaplingCache shmcb:/opt/apache2/logs/ssl_stapling_data(512000)
# Timeout in seconds before invalid responses in the OCSP stapling cache (configured
# through SSLStaplingCache) will expire. The default is 600, which is way too long.
SSLStaplingErrorCacheTimeout 2
# Return unsuccessful stapling related OCSP queries (with an overall status other than
# "successful") on to the client? If set to off, only responses indicating a certificate
# status of "good" will be included in the TLS handshake.
SSLStaplingReturnResponderErrors off
</IfModule>
root@DERWaescheladen:~# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: www.xn--derwscheladen-efb.at-0001
Serial Number: 4cc18e72cd646a544a271a30382a9aeaa4c
Key Type: RSA
Domains: www.xn--derwscheladen-efb.at
Expiry Date: 2023-12-08 15:40:35+00:00 (VALID: 84 days)
Certificate Path: /etc/letsencrypt/live/www.xn--derwscheladen-efb.at-0001/fu llchain.pem
Private Key Path: /etc/letsencrypt/live/www.xn--derwscheladen-efb.at-0001/pr ivkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
root@DERWaescheladen:~# grep -R letsencrypt /etc/apache2/
/etc/apache2/sites-available/ssl-derwaescheladen.at.conf: SSLCertificateFile /etc/letsencrypt/live/www.xn--derwschelad en-efb.at/fullchain.pem
/etc/apache2/sites-available/ssl-derwaescheladen.at.conf: SSLCertificateKeyFile /etc/letsencrypt/live/www.xn--derwsche laden-efb.at/privkey.pem
/etc/apache2/sites-available/ssl-derwaescheladen.at.conf: #Include /etc/letsencrypt/options-ssl-apache.conf
/etc/apache2/sites-enabled/ssl-derwaescheladen.at.conf.save: SSLCertificateFile /etc/letsencrypt/live/www.xn--derwsche laden-efb.at/fullchain.pem
/etc/apache2/sites-enabled/ssl-derwaescheladen.at.conf.save: SSLCertificateKeyFile /etc/letsencrypt/live/www.xn--derws cheladen-efb.at/privkey.pem
/etc/apache2/sites-enabled/ssl-derwaescheladen.at.conf.save: #Include /etc/letsencrypt/options-ssl-apache.conf
/etc/apache2/sites-enabled/ssl-derwaescheladen.at.conf: SSLCertificateFile /etc/letsencrypt/live/www.xn--derwscheladen -efb.at/fullchain.pem
/etc/apache2/sites-enabled/ssl-derwaescheladen.at.conf: SSLCertificateKeyFile /etc/letsencrypt/live/www.xn--derwschela den-efb.at/privkey.pem
/etc/apache2/sites-enabled/ssl-derwaescheladen.at.conf: #Include /etc/letsencrypt/options-ssl-apache.conf
1 Like
There are a few changes we should make but let us fix your Apache cert config first and we will cleanup the rest once we confirm it is working
Change these two lines
SSLCertificateFile /etc/letsencrypt/live/www.xn--derwscheladen-efb.at/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.xn--derwscheladen-efb.at/privkey.pem
To this
SSLCertificateFile /etc/letsencrypt/live/www.xn--derwscheladen-efb.at-0001/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.xn--derwscheladen-efb.at-0001/privkey.pem
Run the sudo apache2ctl graceful and check you are using the new cert with the SSL Checker link I posted earlier
3 Likes
It worked, thank you all.
1 Like
Excellent. Now some further Apache adjustments
This
<VirtualHost _default_:443>
ServerAdmin xxnicoplxx@gmail.com
ServerName www.derwäscheladen.at
ServerName www.xn--derwscheladen-efb.at
Can just be this because the second ServerName replaces the first (see your earlier -D DUMP_VHOSTS output). The ServerAlias is used for the second and other names when needed (not multiple ServerName)
<VirtualHost _default_:443>
ServerAdmin xxnicoplxx@gmail.com
ServerName www.xn--derwscheladen-efb.at
AND, this
<VirtualHost _default_:80>
ServerName www.derwäscheladen.at
Redirect permanent / https://www.xn--derwscheladen-efb.at/
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.derwäscheladen.at
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
Can be this. This will handle the challenge in the HTTP VHost as you currently redirect it to HTTPS. A further improvement is to use a unique DocumentRoot here for the challenges but that requires a change to your Certbot webroot renewal too.
<VirtualHost _default_:80>
ServerName www.xn--derwscheladen-efb.at
DocumentRoot /var/www/derwaescheladen.at
<If "%{REQUEST_URI} !~ m#/\.well-known/acme-challenge/#">
Redirect permanent / https://www.xn--derwscheladen-efb.at/
</If>
</VirtualHost>
You can also delete the now unused original cert files (the ones that are not -0001). You will find them in the /etc/letsencrypt/live and .../archive/ folders
Lastly, you can test your cert renewal with below. Will not affect existing certs.
sudo certbot renew --dry-run
3 Likes