Renew SAN or add a domin in existin SAN

Hello everybody,
I'm new to the forum, sorry if I'm wrong, I ask for help on renewing a SAN that I use on a mail server (dovecot), if anyone has experience on the subject or knows a better system thank you very much for advice and explanations.
I use to manage the SAN, I saw that in the forum if it talks about this and I turn to that here because from the developer I didn't get support. Maybe someone here knows how to help me.
I use the following command

#!/bin/sh --issue -d \
-d --challenge-alias \
-d \
-d \
-d --challenge-alias \
-d --challenge-alias \
-d --challenge-alias \
-d \
-d \
-d \
-d \
-d \
--keylength 4096 --dns dns_ovh --csr /etc/acme/request.csr --cert-file /etc/acme/acmecert/certificato.cer \
--key-file /etc/acme/acmecert/chiave.key --ca-file /etc/acme/acmecert/certificatoCA.cer --fullchain-file /etc/acme/acmecert/fullchain.cer

both to renew the SAN and to add new domains.
The first problem is that before renewing the SAN I have to individually renew the domains that are present in the SAN, with an incredible waste of time, if I don't do this the SAN won't renew itself.
Second problem is that now it uses --challenge-alias for all domains not just some of the first ones where I set --challenge-alias. This causes the process to fail.
Third problem for example
[Thu 22 Jul 2021, 11:56:49, UTC] Removing txt: mejwSpok4xVEV7gGQMCSuehb4NUZaqJoHJd__RviI8M for domain:
[Thu 22 Jul 2021, 11:56:49, UTC] Using OVH endpoint: ovh-eu
[Thu 22 Jul 2021, 11:56:49, UTC] Checking authentication
[Thu 22 Jul 2021, 11:56:50, UTC] Consumer key is ok.
[Thu 22 Jul 2021, 11:56:54, UTC] Removed: Success
It says it has removed the recod txt but it doesn't actually remove anything so I find myself in the DNS with many records that are no longer needed.
Finally for my purpose I can not use the --csr.
is it advisable to switch from to certbot? If yes, someone can tell me how to convert the command I showed using certbot.
Best regard everybody

I'm confused on why you even need to have each mail domain served by a cert that covers that name.
My case in point is Gmail.
If they would be using this model, their certs would have millions of domain names in them.
You are not solving the problem in an efficient manner.
As in the example, the MX records for domains can all be

As for inbound webmail type connections... also the Gmail example.
Plenty of domains get their mail from
If they all need individualized email web sites, then why complicate that by trying to combine all the names into one cert - that won't scale very far.

As for switching from to certbot, you would get more (and better) support from this forum by doing so. And you can easily add certbot as a test without conflicting (much) with your existing use. Once certbot passes your test(s) and you are comfortable with the change, you can then switch to those certs and remove

Thank you very much for the reply. You're absolutely right that I complicated my life, it all started many years ago when there was no need for the certificate and all mail clients were confiugurate each with their own domain. In the configurations that we are doing now, we all have a common domain.
For now I am forced to continue with the SAN at least until September.
Can certbot verify domain ownership via DNS? I don't have a web server on the mail server.
Would you like to help me by giving me some suggestions for switching to certbot?
Thank you very much.

Yes, but it is not as simple to automate, since not all DSPs are prepared for API updates.

Surely; that is why we are here.
First you must understand that adding certbot won't take away anything you are doing.
So you can do both without much conflict.
certbot can be run in standalone mode if there is no web server present. Or with --webroot if there is one available.
So that is my first question: Is there a working web server on that system?
If not, Can port 80 reach that system?
Then we have the issue of domains...
So my second question is: Will you be getting a single cert or multiple certs?
If single cert, Will it have one name or many names?

1 Like

I use ovh and with it worked to insert the txt record

I'm really grateful to you

No and I can't install web server.

There is no service listening on that port, it is not used

I need to have a single certificate with many names. Am I wrong or is this system called SAN?

For information, I need:
--cert-file certificate.cer
--key-file filekey.key --ca-file certificateCA.cer --fullchain-file fullchain.cer, these are some of the parameters I use with

I hope, I have quoted well and that the writing respects the rules of the forum.

1 Like

Is there a firewall (or NAT device) that can route inbound port 80 requests to this system?
Or is port 80 already being used by some other system?

Yes there is a firewall (iptables), which I manage so if you need to do something with port 80 I can do it. The system is debian 11, I love debian!
Best regards

So there is no other device in line - this server has the Internet IP.
Then you only need to allow port 80 through iptables and start an ACME client in standalone mode to validate inbound HTTP challenge requests.


Yes I think so, I did not know that ACME mode used port 80, sorry for my ignorance.

1 Like

No problem - was were all ignorant once :slight_smile:
But now you know.
HTTP validation is the simplest.
Having an ISP that allows inbound HTTP is great for this.
You don't need a web server on port 80 at all - you can run ACME clients in standalone mode and they will spin-up a temporary web server only to serve the challenge requested file and then shut down.

That said, multiple ACME clients can do this.
And multiple ACME clients can be installed and operate on the same system (just not at the same exact time).

So I propose you add certbot and start testing (with --staging or --dry-run) before making anything production/permanent.

You should not use the exact same file names and locations - doing so will overwrite your working certs.

See if you can follow these installation instructions (for Deb10) on your system:
Certbot - Debianbuster Other (

Thanks a lot for the explanations, I start testing certbot on a local server (lan) which is similar to the production one to work more peacefully. If I can and you like, I update this post with the progress I can make independently. Thanks again, now I have to go home otherwise my wife gets angry and it's terrible :scream:

1 Like

Yes yes:
Happy wife = Happy life ! ! !

Hi Goodmorning.
Hi Goodmorning. I have installed and am starting to get familiar with the options. is it possible to delegate a domain on ovh to verify one on an ISP that has no API? I explain with if I need to validate a "registered" domain on a provider that does not have API I add a CNAM record on this domain that points to a domain that I manage with OVH and therefore that has the API.
For example "CNAME" is on ISP without API, is on OVH.
Thank you very much
Edit: Sorry, I just read @jmorahan post pointing to use this method, but there are prameters to add at command line?

Edit2: I tried but it doesn't work :worried:

Reading your conversation with @rg305 above, it seems you probably don't need to use DNS validation at all. If your port 80 is reachable, you can just use HTTP validation. Pass the --standalone option to certbot and remove any DNS related options. You don't need any CNAME records at all in this case, just make sure your firewall isn't blocking port 80.

If you really want to continue with DNS validation: I don't know if certbot has a direct equivalent of's --challenge-alias option. It didn't when I last looked for it, but that was quite some time ago, so it may have been added since. You could, of course, write your own scripts to interact with OVH's DNS API and call them via certbot's --manual-auth-hook / --manual-cleanup-hook options (documented here). But that seems like an awful lot of unnecessary work if you can just use HTTP validation instead.

Alternatively, I can guess why wasn't working correctly for you: its parameter order is somewhat unusual and (I find) confusing. I think the safest way to use it is to list all the domains that don't require an alias, before any of the ones that do. As in: --issue -d \
-d \
-d \
-d \
-d \
-d \
-d \
... other non-aliased domains ... \
-d --challenge-alias \
-d --challenge-alias \
-d --challenge-alias \
-d --challenge-alias \
... etc
1 Like

Thanks for your contribution,

Could you please explain to me how it can verify domain ownership if I remove the DNS since this SAN is used on a mail server not a web server?

you are absolutely right that the script is confusing, but even changing the order by moving the aliases towards the end the result does not change the last check times out. What I don't understand is why until last month without any changes it stopped working, as I said it's a renewal not a new SAN.
Thank you very much.

If you use the --standalone option, certbot will start up its own temporary web server for the duration of the challenge validation, and shut it down afterwards.

Of course you still need an A or AAAA record for the actual domain but you don't need the CNAME for the _acme-challenge subdomain.

That sounds like a new and different problem to what you described before. Sharing the output from that attempt might help (but I'd recommend trying standalone mode first).

1 Like

Certbot match server IP addres with A or AAAA records?

News: Without any changes I tried to renew using with the usual command and it was successful !!

Although now the next deadline is in September, I would like to learn more about the use of certbot and the letsencrypt API. Advice on this?

If you use one of the challenges that requires an IP address (whether using certbot,, or any other client), Let's Encrypt looks up AAAA and A records to find the IP address for the domain.

Glad to hear it :slight_smile: Perhaps that timeout was just a temporary problem.

If you want to learn about the use of certbot, its user guide is a good place to start. Regarding Let's Encrypt in general, there's some documentation here - in particular I'd suggest reading the page about Challenge Types which seems relevant to your situation.

1 Like

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