Don't understand the processes by renew

I create a wildcard Cert with the following command.

certbot certonly --manual
--preferred-challenges=dns
--email xxxxxxx@freenet.de
--server https://acme-v02.api.letsencrypt.org/directory
--agree-tos
--manual-public-ip-logging-ok
-d "*.xxxxxx00000.eu"

Then I look in cron.jobs and put this line in
0 */12 * * * root perl -e 'sleep int(rand43200))' && certbot -q renew

For teststing certbot-comand I try it in Command line
/etc/cron.d/certbot

Following Dialog in TerminalWindow:
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: g00000.xxxxx00000.eu


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for g00000.xxxxx00000.eu
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-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
Added an HTTP->HTTPS rewrite in addition to other RewriteRules; you may wish to check for overall consistency.
Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf


Congratulations! You have successfully enabled https://g00000.xxxxxx00000.eu

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=g00000.xxxxx00000.eu


IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/g00000.vitrain-00000.eu/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/g00000.xxxxx00000.eu/privkey.pem
    Your cert will expire on 2022-03-05. 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"

  • Some rewrite rules copied from
    /etc/apache2/sites-enabled/000-default.conf were disabled in the
    vhost for your HTTPS site located at
    /etc/apache2/sites-available/000-default-le-ssl.conf because they
    have the potential to create redirection loops.

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let's Encrypt: Donate - Let's Encrypt
    Donating to EFF: Support EFF's Work on Let's Encrypt | Electronic Frontier Foundation

Bash carries out the following query at least the first time (see Appendix 1)
whereby a new file is created and this is entered in an Apache2 file,
were already there until they were run
000-default.conf and default-ssl.conf,
now 000-default-le-ssl.conf is added

and this file is saved in / etc / apache2 / sites-available
Content of the file in this content:
(especially the last lines even though it is a wildcard certificate)
a directory is also created in letsencrypt with a left on the wildcard certificate

Now look at the botton of the file, new Keys with hostname.

<VirtualHost *:443>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerName "g00000.xxxxx00000.eu"

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

RewriteEngine on
    # Some rewrite rules in this file were disabled on your HTTPS site,
    # because they have the potential to create redirection loops.
    
    #         RewriteCond %{HTTPS} off
    #         RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
    RewriteCond %{SERVER_NAME} ="g00000.xxxxx00000.eu"
    RewriteRule ^ https//%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]


# 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}/error.log
CustomLog ${APACHE_LOG_DIR}/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

SSLCertificateFile /etc/letsencrypt/live/g00000.xxxxxx00000.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/g00000.xxxxx00000.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

The Certbot builds a new certificate with the host because I selected redirect, and what would happen if I didn't do that.

I couldn't wait for an automatic renew either, so I'm asking here.

I hope the renew process will run the second time without asking and the automatic system will work.

Should I do something differently to make sure it works.

certbot builds a new cert with the host because you selected "1":

certbot updates the HTTP config to include HTTP to HTTPS redirection when you choose "2":

If you hadn't chosen "2", it would have still built "000-default-le-ssl.conf".
But it would have left "000-default.conf" without change.

Please show:
apachectl -t -D DUMP_VHOSTS

1 Like

Thanks for your help Rudy.

I have now deleted the xxxxx00003.eu with certbot delete.

Do I now have a normal certificate or a wildcard certificate with letsencrypt?

My 000-default-le-ssl.conf look like this.

ServerAlias gcs3.xxxxx00003.eu
SSLCertificateFile /etc/letsencrypt/live/gcs3.xxxxx00003.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/gcs3.xxxxxx00003.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

Maybe you can still remember. A few weeks ago I asked a few questions about wildcard and renew on many servers.
I have now decided that I will not apply for any wildcards.
There are too many problems and dependencies when it runs on many servers.
It seems to me to be easier and more stable to equip all servers with simple certificates, even if I have to apply for and pay for a separate domain for each server.
I can also use a standardized script for the configuration of the server.

But there is one thing I want to ask again before I adapt the script for the server config.
Can I apply for a certificate for, for example: abcd.mydomain.mytoplevelldomain.

Yes*
For HTTP authentication: As long as the name can be resolved to an Internet IP and HTTP can reach that IP.
OR
For DNS authentication: As long as the authoritative DNS servers can be reached and the TXT records can be verified.

1 Like

PS.
The file /etc/apache2/sites-available/default-ssl.conf still refers to
live / xxxxx000003.eu although this directory no longer exists after the delete.

And the certificate is now stored at Letsencrypt as a wildcard or individual certificate.

I changed the default ssl.conf and restarted apache, there were no problems.

Is there a way to check certificate typ.

Yes.
Copy the cert.pem file into a Windows computer.
Rename it to cert.crt
Then double-click it.

There on the details page, you can find all the Subject Alternate Names covered by that cert:


If you see any "*" in the names, then there exists a wildcard entry.
If you don't, then there aren't any.

1 Like

If have try, it works, no wildcard.
Thank you.

What do you think of my decision to plan a separate certificate for each server and to forego the wildcard.

One more question.

I just started certbot from cron.d and the questions were asked again,
So I had to answer that with 1 and 2.

How should that work when it is executed by the CronJob. Then there is no one who can answer. Did I do something wrong in the CronJob Config, or is that just because I only used certbot in Comand and didn't use -q renew.

0 * / 12 * * * root perl -e 'sleep int (rand43200))' && certbot -q renew

That's how most people do it.
[HTTP authentication is much simpler than DNS authentication]

It will only renew (as it should).

No, it looks correct to me.

2 Likes

I'm not sure if @joob is still using

but typically --manual is not compatible with certbot renew or unattended automated renewal.

@joob, if you switched away from --manual to a different method, as I think @rg305 was encouraging you to do, then certbot renew should be able to run without prompting you for anything, once you already have your certificate. Certbot remembers your answers to its questions in a "renewal configuration file" in /etc/letsencrypt/renewal, which is what certbot renew starts with when deciding what to renew and how to renew it. However, the --manual method poses problems for this because it always requires human interaction to complete the authentication challenges, unless you specify a script with --manual-auth-hook to substitute for that interaction.

Other methods use Certbot's built-in integration with web servers to complete the authentication challenges in software, so they won't require you to answer questions during a renewal, only when you obtain the certificate for the very first time.

3 Likes

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