How to add domain to /etc/letsencrypt/renewal/.conf file

I have created new websites served by my web-firewall and web-server that I want to have certs for. I inherited this whole system and how to make certs etc. It seems like a hack as in /etc/httpd/sites-devel exsist these .conf files that say:

<VirtualHost *:80>
     ServerAlias appname
     DocumentRoot /var/www/html

so this script that runs the certbot-auto force renewal, moves sites-devel to sites-enabled. Then forces the renewal then moves sites-enabled back to sites-devel and recovers the original sites-enabled from a it got moved to. I understand this process, it is faking the webroot for all our apps running on our webserver.

The problem is, I have added my new app in this folder with the same conf file with the right appname. Though when I add this app tot he bottom of my /etc/letsencrypt/renewal/ file
then it says a parse error. what I don't understand is I have two apps, and I can add to the conf file:

version = 1.10.1
archive_dir = /etc..lets... 
cert  = /etc...lets...
privkey = /etc..lets...
chain = /etc..lets...
fullchain = /etc...lets...
# Options used in the renewal process


authenticator = webroot
account = blargblarg
server =
manual_public_ip_logging_ok = None

... =  /var/www/html

the above has no parse error, if I take out the = /var/www/html it has no parse error. If I though add this domain: = /var/www/html

Parse it seems it is looking somewhere else based on this I am just not sure where... I just inherited this whole web server and I am still coming to grips on how the certbot certs work.

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. |, 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:
/opt/certbot/certbot-auto renew --force-renewal

It produced this output:
parse error in .conf file

My web server is (include version):

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

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

Hi @codejoy,

Certbot doesn't store its list of "desired domains" ("requested domains"?) anywhere in the renewal configuration file itself. (This was something we debated when originally creating Certbot.)

The webroot_map section of the renewal configuration file is intended to help with the situation where you are using the --webroot method and have a certificate covering several virtual hosts which individually have different webroot directories from one another (typically because they are serving different content). The webroot_map helps Certbot to find which webroot directory ought to be used for each domain.

However, it's not something that motivates Certbot to attempt to add domain names to a certificate if they aren't already present in that certificate.

The intended way to add domains to a certificate is to re-run certbot certonly with a --cert-name option to indicate which certificate to act on, and a list of -d options including every desired name for the new certificate. (Not just the new ones—all of them!)

When using the --webroot method you can add at least one -w option to specify a webroot. If you have different webroots for different virtual hosts, you can use multiple -w options with multiple -d options, like -w /var/www/ -d -w /var/www/ -d These will get saved in the renewal configuration's webroot_map section if the certificate request is successful.

Certbot actually gets the current list of names for a certificate from the PEM file on disk containing the current certificate, meaning that this list is only ever stored anywhere after a certificate is successfully issued for that list of names.


Okay thank you for this information, and I realized in my post I should of stated this was indeed for many different virtual hosts. Apps that are hosted sometimes on other machines too. Our web-firewall is running this apache as a ...reverse proxy I think it is called? and that is also where all the certbot magic is happening.

So all my testing and seeing the parsing fail, got me banned for 168 hours I think it said :smiley: .

But this --webroot method you speak if, does seem like the method being used, though the command I believe is that simple certbot-auto forcerenewal.
Still a bit confused though, does that meant he renewal.conf file does not need the new virtual hosts I am running in it as I create them?

I did on my own run some commands so slopily because I had no idea what I was doing...but I ran:

/opt/certbot/certbot-auto certonly --webroot -w /var/www/html -d
To which this worked, for that specific app and then in the /etc/httpd/covid19-ssl.conf file it had a:
include extras/covid19-ssl-certs file which has:

SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
SSLCertificateChainFile /etc/letsencrypt/live/
Include /etc/letsencrypt/options-ssl-apache.conf

So the live/ folder was created though is much seperate from the 'generic' folder all the other virtual hosts used. I did try to get my covid19 app to run like the other virtual hosts with the including of the generic ssl certs that lived in letsencrypt/live/ folder.

Which I guess ultimately I am trying to do, is make the new apps I am creating covid19 and kronos to behave like the ones already deployed. Which all pointed to /etc/letsencrypt/live/ for all their *pem files somehow.

1 Like

Testing should be done on the staging server.........


The authenticator method that was originally used to obtain the certificate is saved in the renewal configuration file and used for subsequent renewals, even if it's not re-specified.

I would say that there's no useful way to add them by editing this file yourself. In general, individual domain names don't need to be referenced in a Certbot renewal configuration file at all (they're taken from the certificate itself). When using webroot, they do end up getting referenced in the webroot map if they individual domains that are covered by a single certificate have different webroot directories.

If you request a new certificate without specifying --cert-name and the new certificate's domains don't include all of the domains from some prior certificate, Certbot creates a new separate certificate. If you want to add new domains to an existing certificate, you should use --cert-name to refer to that certificate when running Certbot, but you will also need to list both the old and new domain names in your command.

You can choose whether you want new domain names to be covered by re-issuing an old certificate with additional names, or to be managed in separate certificates. Certbot will support both approaches.


Thanks again, it helps me to uncover what the last person before me did to initially get the certs it seems that is my next portion to sluth. My what felt like a clunky plan was really to just do this:

/usr/sbin/apachectl stop
cd /etc/httpd
/bin/mv sites-enabled
/bin/mv sites-devel sites-enabled
/usr/sbin/apachectl start
/opt/certbot/certbot-auto certonly --webroot -w /var/www/html -d
# Switch back to vhosts
/usr/sbin/apachectl stop
/bin/mv sites-enabled sites-devel
/bin/mv sites-enabled
/usr/sbin/apachectl start

Then I was going to do that for all domains and just update their included files to point to the right

I guess this managed via separate certificates. This is the way that makes sense to me, though it does feel clunky. What I cannot wrap my brain around is how the certificates for each virtual host originally got somehow all smashed into one set of certs .pem files that works for any of the hosts... clearly I have a lot to learn

1 Like

If you are going to do more "experimenting" or testing, you should use the staging server as @Osiris mentioned. At the end of your Certbot command add --dry-run. Test to your hearts content and you won't hit the limit you did before - and get "locked out" again. :wink:


Each time you run Certbot, it gets one certificate, and a single certificate can cover up to 100 names. (The technology apparently allows thousands of names, but Let's Encrypt's policy is no more than 100 per certificate.)

If you put lots of -d options in your Certbot command, you get a certificate that covers lots of different names—up to 100 of them. It will be valid for any listed name.

There are advantages and disadvantages for both the "one big certificate" style and the "many small certificates" style.


So I tried it with the dry run, got a ascii error
/opt/certbot/certbot-auto certonly --webroot -w /var/www/html -d --dry-run

"Non-ASCII domain names not supported. To issue for an Internationalized Domain Name, use Punycode."

Did I need quotes around the domain name? I haven't ever heard of punycode, upon reading more it doesn't seem to apply because afaik the domain name is all standard ascii characters?

now I am also wondering, if I have my sites-devel (which has those simple confs of all virtual hosts with the same /var/www/html web root) set as my sites-enabled with apache running....can I just issue this command:

sudo certbot certonly --apache

and have it refresh/remake all the certs for everything in that folder where certbot-auto renew works in the future?

I guess that is the big question is I like the one big certificate I just want to add all the new virtual hosts I have added to these certs somehows. What I tried/thought I was doing in my initial post.

1 Like

Did you somehow paste the domain name from a spreadsheet or e-mail or something that might have an invisible formatting character? I agree that your domain name is all ASCII and this shouldn't apply.

1 Like

The --apache method still only gets a single certificate per Certbot run. It's more about how Certbot handles the authentication process (you wouldn't need to specify an individual webroot or webroots) than about how the certificates are organized or the relevant domain names are chosen.

The --apache method, if you run it interactively, would prompt you to choose a domain name or domain names based on those that it can detect in your Apache configuration. So you could use that interactive selection instead of supplying -d options. You would still have a choice about how many names are included on a single certificate; you could have that be "all of them" or "just one" based on your name selections in response to the prompt.

However, there is no feature to "expand this certificate automatically to cover newly added virtual hosts' domains"; you still have to re-run Certbot and explicitly select those names after the virtual hosts are added.


That did it, it had trailing white space I didn't catch.

I think I am going to go with individual certs and thusly will be running
sudo certbot-auto certonly --webroot -w /var/www/html -d

for all my virtual hosts. Then I am assuming certbot-auto renew figures out what is in the /etc/letsencrypt/live and will renew those (actually guessing it is based whats in the /renewal as it has all the .conf of the new -d domains I just added)...

1 Like

It's based on both. /etc/letsencrypt/renewal provides the list of certificates to attempt to renew, and /etc/letsencrypt/live provides the domains that should be included in each. Again, [[webroot_map]] does not provide a list of domains to attempt to renew, but does give information about how to renew a certificate for a particular certificate, if Certbot decides to attempt to do so.


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