security/acme-client: duplicate Common Names break acme.sh configuration

[PotatoCarl]

Describe the bug
Using the ACME plugin with OPNSENSE 22.7 out of the box
My last successful updated certificate is from June (3 months old).
The protocol claims to have updated the certificate and stored it in the certificate store.
However, there is only the "old" certificate.
When activating the Staging signing facility, there is no problem and immedaitely a new certificate is issued.
To Reproduce
Steps to reproduce the behavior:

1. Setup the acme pluging
2. Wait

Expected behavior
New certificate stored in certificate store

Relevant log files
Plugin Log:

2022-09-15T00:00:11	opnsense	AcmeClient: updated ACME X.509 certificate: rocket....
2022-09-15T00:00:11	opnsense	AcmeClient: successfully issued/renewed certificate: rocket....
2022-09-15T00:00:02	opnsense	AcmeClient: using challenge type: HTTP-Challenge_bckup
2022-09-15T00:00:01	opnsense	AcmeClient: account is registered: BRAXXXXX
2022-09-15T00:00:01	opnsense	AcmeClient: using CA: letsencrypt
2022-09-15T00:00:01	opnsense	AcmeClient: renew certificate: rocket....
2022-09-15T00:00:01	opnsense	AcmeClient: certificate must be issued/renewed: rocket....

ACME Log:

2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] Installing full chain to: /var/etc/acme-client/certs/627608fddcabd7.68944490/fullchain.pem
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] Installing key to: /var/etc/acme-client/keys/627608fddcabd7.68944490/private.key
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] Installing CA to: /var/etc/acme-client/certs/627608fddcabd7.68944490/chain.pem
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] Installing cert to: /var/etc/acme-client/certs/627608fddcabd7.68944490/cert.pem
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] And the full chain certs is there: /var/etc/acme-client/home/rocket/fullchain.cer
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] The intermediate CA cert is in: /var/etc/acme-client/home/rocket/ca.cer
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] Your cert key is in: /var/etc/acme-client/home/rocket.brace.de/rocket.key
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] Your cert is in: /var/etc/acme-client/home/rocket.brace.de/rocket.cer
2022-09-15T00:00:09	acme.sh	[Thu Sep 15 00:00:09 CEST 2022] Cert success.
2022-09-15T00:00:08	acme.sh	[Thu Sep 15 00:00:08 CEST 2022] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/03c2ebd8be15d961183ed20622c6ab32e72f'
2022-09-15T00:00:08	acme.sh	[Thu Sep 15 00:00:08 CEST 2022] Downloading cert.
2022-09-15T00:00:07	acme.sh	[Thu Sep 15 00:00:07 CEST 2022] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/237870340/125531643127'
2022-09-15T00:00:07	acme.sh	[Thu Sep 15 00:00:07 CEST 2022] Lets finalize the order.
2022-09-15T00:00:07	acme.sh	[Thu Sep 15 00:00:07 CEST 2022] Verify finished, start to sign.
2022-09-15T00:00:07	acme.sh	[Thu Sep 15 00:00:07 CEST 2022] rocket.brace.de is already verified, skip http-01.
2022-09-15T00:00:06	acme.sh	[Thu Sep 15 00:00:06 CEST 2022] Getting webroot for domain='rocket...'
2022-09-15T00:00:03	acme.sh	[Thu Sep 15 00:00:03 CEST 2022] Getting domain auth token for each domain
2022-09-15T00:00:03	acme.sh	[Thu Sep 15 00:00:03 CEST 2022] Single domain='rocket....'
2022-09-15T00:00:03	acme.sh	[Thu Sep 15 00:00:03 CEST 2022] Using CA: https://acme-v02.api.letsencrypt.org/directory
2022-09-15T00:00:02	acme.sh	[Thu Sep 15 00:00:02 CEST 2022] Renew: 'rocket....'

Environment

OPNsense 22.7.4-amd64
FreeBSD 13.1-RELEASE-p2
OpenSSL 1.1.1q 5 Jul 2022

[OPNsense-bot]

Thank you for creating an issue.
Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.

For more information about the policies for this repository,
please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

The easiest option to gain traction is to close this ticket and open a new one using one of our templates.

[fraenki]

The protocol claims to have updated the certificate and stored it in the certificate store. However, there is only the "old" certificate.

I've never seen this issue anywhere. How do you verify if the certificate was updated?

[PotatoCarl]

As you can see in the logs, "Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/237870340/125531643127'" the script is supposed to download the updated certificate.

BTW: I stopped the automatic cron update and manually updated it after a couple of days, not touching anything until then, and then (with the same log entries) I received a new certificate (using the button "forcefully renew the certificate"). Then I could use th automations to get it into my server. However, this does not seem to be a permanent solution as the script should automatize it.
I have changed the time between signature trials to 7 days and wonder if that may be an issue (need to wait 3 months to be sure...)

[fraenki]

Did you check System: Trust: Certificates if the certificate is updated there?

Then I could use th automations to get it into my server.

So you are using an Acme Automation to send the certificate to your server, right? This is missing from the logs you've provided. :( Please provide some details about the Automation and log entries that show a failed attempt.

[PotatoCarl]

The automation worked fine always. It was always the old certificate in the storage, so even when I checked the storage on my OPNSENSE box, the certificate showed an expiry of Sep 15/2022. I could copy it (via SFTP) to the server, but it was still the old certificate.
It seems as the script did not renew the certificate at any time. The automation worked fine.

[fraenki]

[Thu Sep 15 00:00:09 CEST 2022] Installing cert to: /var/etc/acme-client/certs/627608fddcabd7.68944490/cert.pem

Well, acme.sh claims to have renewed the certificate. Please run the following command:

openssl x509 -noout -text -in /var/etc/acme-client/certs/627608fddcabd7.68944490/cert.pem | grep -A2 Validity

And provide the output here.

[PotatoCarl]

Well, unfortunately (see my posting above) I could renew it manually after many tries. I (as written) have changed the cron job from daily to weekly and try to find out if that is the reason. As the certificate is now shown as renewed until Dec 2022 I will actually have to wait to see if it will be renewed. I assume that the "old" certificate is removed when renewed. Please correct me if I am wrong, then I will do what you propose.
However, what I did before was manually downloading the certificate from the OPNSense certificate storage and do the check locally on my linux system finding that the certificate was valid until September 15... So either it was not integrated into the certificate store, or it was now renewed correctly despite the log message above. Neither can be clearly identfied by myself.

[ahgraber]

I am also having this issue. I recently noticed ACME client is renewing LetsEncrypt cert daily. Further investigation indicates it is not registering the new certs in OPNsense System > Trust > Certificates.

Navigating to Services > ACME client > Log Files (/ui/acmeclient/logs) reports it thinks the cert needs to be renewed: "AcmeClient: certificate must be issued/renewed: opnsense.example.com".
Logs show successful renewal. In the Services > ACME client > Certificates (/ui/acmeclient/certificates) shows the cert has been renewed.
However, System > Trust > Certificates (/system_certmanager.php) shows the old cert, and checking the cert with my browser shows the old cert.

It appears the ACME client is not writing the cert to OPNsense's trust storage. I have tried to reimport the cert, but nothing changes.

Further info:
I had previously run into an issue where the webUI wasn't registering the new cert, and I resolved that by adding an automation to restart the webUI. However in that case (IIRC), the cert did not keep on renewing, it was simply that the browser would show warnings about the expired cert.

I have tried removing the old cert from the Trust Store, and re-importing from the ACME client certification. The cert DOES reappear in the trust store, but it is the old cert, not the cert.

Logs:
combined configd.log filterd for "acme", "certificate", "trust"
configd warnings.log
acme.log
system.log

I could not identify where to get logs for the trust store

Running:
OPNsense 22.7.10_2-amd64
FreeBSD 13.1-RELEASE-p5
OpenSSL 1.1.1s 1 Nov 2022
os-acme-client (installed) 3.14_1; renewing cert using DNS validation

[ahgraber]

pinging @fraenki just to ensure you see new activity with this report.
Another user has reported similar issues in the forum

[fraenki]

2023-01-05T01:00:08-05:00 opnsense AcmeClient: updated ACME X.509 certificate: opnsense.mydomain.com
2023-01-05T01:00:08-05:00 opnsense AcmeClient: successfully issued/renewed certificate: opnsense.mydomain.com
2023-01-05T01:00:01-05:00 opnsense AcmeClient: using challenge type: Cloudflare DNS Challenge
2023-01-05T01:00:00-05:00 opnsense AcmeClient: account is registered: mydomain
2023-01-05T01:00:00-05:00 opnsense AcmeClient: using CA: letsencrypt
2023-01-05T01:00:00-05:00 opnsense AcmeClient: renew certificate: opnsense.mydomain.com
2023-01-05T01:00:00-05:00 opnsense AcmeClient: certificate must be issued/renewed: opnsense.mydomain.com

I cannot spot any errors related to Acme Client in the provided logs. Everything looks good to me, so at first glance there's nothing I can do about it.

Some ideas for further investigation:

1. Maybe you've set the renewal interval to one day? Please verify in the Acme Client certificate settings.

2. Maybe there's something wrong with the internal certificate data? Please manually check your config.xml (either export the config backup or have a look at /conf/config.xml). Try to find the System -> Trust -> Certificated entry for the affected certificate in config.xml, it should look similar to this:

  <cert>
    <refid>61d6efdcc4738</refid>
    <caref>60d8dceae0fa5</caref>
    <descr>opnsense.example.com (ACME Client)</descr>
...

Next try to find the Acme Client entry for the affected certificate in config.xml:

    <AcmeClient version="3.4.0">
...
      <certificates>
...
        <certificate uuid="5d308aed-645e-4644-9d41-f4a5691965d1">
          <id>61d6ef31cbd065.47854255</id>
          <enabled>1</enabled>
          <name>opnsense.example.com</name>
...
          <certRefId>61d6efdcc4738</certRefId>
          <lastUpdate>1672663460</lastUpdate>
          <statusCode>200</statusCode>
          <statusLastUpdate>1672663461</statusLastUpdate>
...

Now compare the certRefId from the Acme Client entry with the refid from the System -> Trust -> Certificated entry. It should match.

3. Set Log Level to debug in Services: ACME Client: Settings. This will mess up the ACME Log files in the GUI, but it should provide more details why Acme Client thinks it needs to renew the certificate.

[ahgraber]

Certs are scheduled to check if renewal is required daily, but renewal interval is 60.

The certRefId is 63b97e032986f, and matches the refid 63b97e032986f

I'm currently rate-limited by letsencrypt because of the daily renewals; I have set loglevel=debug and will report back once I attempt a manual renewal.
I tried with letsencrypt staging earlier, and I had to revoke the in the ACME client and remove it from the trust store, then issue the cert. Only then did the updated staging cert appear in the trust store.

[Grandma-Betty]

Came here because of the same issue I guess.
Certificate renewals were working for over a year now without any hiccups and then suddenly the automation was not working anymore, all certificates got run out of validation.
Rebooting the system and issuing all certificates manually again did work out though.
Not sure if I will run into the same issue again after 60 days, just wanted to confirm here that something seem to go wrong currently.

[ahgraber]

@fraenki The cert tried to autorenew this morning with the same issue. Here are the logs:
system-jan9.log
acme-jan9.log

I was able to successfully renew after completely nuking my cert setup and rebuilding. I have not yet validated that a renewal will update the cert in the trust store.

For those with the same issue, you can manually renew by:
1. in system > settings > Administration: set your webgui cert to the self-signed (if using chrome this may mean you have to type thisisunsafe into the void every time the window refreshes)
2. in system > trust > certificates: delete the cert with the renewal problem
3. in system > trust > authorities: delete the letsencrypt authorities
4. in services > ACME client > certificates: revoke, reset, and remove the cert
5. in services > ACME client > accounts: remove all letsencrypt accounts
6. in services > ACME client > accounts: recreate the letsencrypt accounts
7. in services > ACME client > certificates: create a new cert (maybe try with staging first)
8. check system > trust > certificates to verify your new cert has installed properly
9. reset the webgui cert in system > settings > Administration

[fraenki]

2023-01-09T01:00:00-05:00 opnsense AcmeClient: ignoring disabled certificate: opnsense.mydomain.com

Acme Client thinks that your certificate is disabled in the GUI.

I was able to successfully renew after completely nuking my cert setup and rebuilding.

So I'm assuming that finding the root cause for your issue will not be possible anymore... :-/

For those with the same issue, you can manually renew by:

I STRONGLY discourage everyone from doing this. If there's a bug, let's try to find the root cause. If you follow these steps there's nothing we can do anymore.

[ahgraber]

Acme Client thinks that your certificate is disabled in the GUI.

I'm pretty sure that's referring to the staging cert that has the same name? I had it disabled b/c I did not want it to continuously renew

So I'm assuming that finding the root cause for your issue will not be possible anymore... :-/

Possibly? Based on what I could grok from the ACME logs, it seemed like the issue was the integration between the ACME client and the OPNsense trust store, not the cert renewal process itself.
I wanted (a) to have a valid cert, and (b) to be able to experiment to see whether the new cert would be updated when renewed. I will force-renew the cert (tomorrow or next week) to test whether it successfully gets propagated to the OPNsense trust store.

[fraenki]

I'm pretty sure that's referring to the staging cert that has the same name?

Do they share the same name? Pretty confusing, but now the log entry makes sense.

Based on what I could grok from the ACME logs, it seemed like the issue was the integration between the ACME client and the OPNsense trust store

What exactly leads to this conclusion? I was not able to identify this from the logs.
And, FWIW, I'm using dozens of Acme certs across many firewalls, with not a single "integration issue" or trust store issue.

[ahgraber]

They did share the same name... I wasn't sure how to change, since the description field doesn't seem to impact the name, and the name seems to be derived from the common name field? I was hesitant to add parethenticals or descriptors to the common name.

What exactly leads to this conclusion?

The logs for ACME showed a successful renewal. The ACME UI indicated an updated cert renewal date. It is only the OPNsense trust store UI (and therefore, the browser window) that did not use the updated cert, even after using (re-)import certificate in the ACME UI

... in retrospect, I did not think to run openssl x509 -in fullchain.pem -noout -text on the cert file itself to check whether it was updated. I will do so when I force-renew the currently-working cert in a few days

[fraenki]

They did share the same name... I wasn't sure how to change

The certificate name cannot be changed. Changing the CA of a certificate is also not supported. If you need to test something with a different CA (Let's Encrypt Staging), I'd recommend to create a 2nd certificate for this purpose (as you did).

... in retrospect, I did not think to run openssl x509 -in fullchain.pem -noout -text on the cert file itself to check whether it was updated

We definitely need more information to make some progress on this issue. I don't know what we're looking for, because the logs do not indicate any issue.

Maybe we need (in addition to the previously mentioned logs)....

1. A screenshot of the outdated entry in System > Trust > Certificates (cert name may be obfuscated)
2. Verify the Acme cert lifetime, as suggested:

openssl x509 -noout -text -in /var/etc/acme-client/certs/CERT_ID/cert.pem | grep -e 'Not ' -e 'Subject:'
            Not Before: Jan  2 11:44:19 2023 GMT
            Not After : Apr  2 11:44:18 2023 GMT
        Subject: CN = opnsense.example.com

Maybe provide the full output of the openssl command, just in case...

[skipperTux]

Having the same issue, ACME certificates renew not working (anymore) last ACME status "internal error". Manual update works, tested with the staging environment that did have the same error using automation. OPNsense, packages and plugins are up to date.
From the logs it looks like the certificate paths do not match, 634c116f6097a2.72834012 vs. 634c119619e747.53710732.

[ACME Log]
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] The NOTIFY_HOOK is empty, just return.
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] _on_issue_success
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] Installing full chain to: /var/etc/acme-client/certs/634c116f6097a2.72834012/fullchain.pem
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] Installing key to: /var/etc/acme-client/keys/634c116f6097a2.72834012/private.key
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] Installing CA to: /var/etc/acme-client/certs/634c116f6097a2.72834012/chain.pem
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] Installing cert to: /var/etc/acme-client/certs/634c116f6097a2.72834012/cert.pem
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] And the full chain certs is there: /var/etc/acme-client/home/*.sub.example.org_ecc/fullchain.cer
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] The intermediate CA cert is in: /var/etc/acme-client/home/*.sub.example.org_ecc/ca.cer
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] Your cert key is in: /var/etc/acme-client/home/*.sub.example.org_ecc/*.sub.example.org.key
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] Your cert is in: /var/etc/acme-client/home/*.sub.example.org_ecc/*.sub.example.org.cer
2023-01-12T02:34:08	acme.sh	[Thu Jan 12 02:34:08 CET 2023] Cert success.

[System Log]
2023-01-12T02:34:08	php	AcmeClient: failed to import certificate: *.sub.example.org
2023-01-12T02:34:08	php	AcmeClient: unable to import certificate *.sub.example.org, file not found: /var/etc/acme-client/certs/634c119619e747.53710732/cert.pem
2023-01-12T02:34:08	php	AcmeClient: successfully issued/renewed certificate: *.sub.example.org
2023-01-12T02:34:04	php	AcmeClient: running acme.sh command: /usr/local/sbin/acme.sh --renew --syslog 7 --debug --server 'letsencrypt' --dns 'dns_hetzner' --dnssleep '120' --home '/var/etc/acme-client/home' --certpath '/var/etc/acme-client/certs/634c119619e747.53710732/cert.pem' --keypath '/var/etc/acme-client/keys/634c119619e747.53710732/private.key' --capath '/var/etc/acme-client/certs/634c119619e747.53710732/chain.pem' --fullchainpath '/var/etc/acme-client/certs/634c119619e747.53710732/fullchain.pem' --domain '*.sub.example.org' --days '1' --keylength 'ec-384' --ecc --accountconf '/var/etc/acme-client/accounts/634c0a9727b6e7.14144761_prod/account.conf'
2023-01-12T02:34:04	php	AcmeClient: using challenge type: Hetzner DNS
2023-01-12T02:34:04	php	AcmeClient: account is registered: LE Production
2023-01-12T02:34:04	php	AcmeClient: using CA: letsencrypt
2023-01-12T02:34:04	php	AcmeClient: renew certificate: *.sub.example.org
2023-01-12T02:34:04	php	AcmeClient: certificate must be issued/renewed: *.sub.example.org

[fraenki]

From the logs it looks like the certificate paths do not match, 634c116f6097a2.72834012 vs. 634c119619e747.53710732.

Did you restore OPNsense from a backup or something like that?

[skipperTux]

No, this OPNsense instance is installed using Ansible (with a mix of using the API, if possible, or changing the config.xml and reloading using configctl).
(Edit) However I am using an empty config.xml as a starting point (like from an "initial backup"). Is this a problem?
This OPNsense instance is running for more than 8 month without any issues, ACME and HAProxy have been added 3 months ago.

[fraenki]

@skipperTux From the logs it seems that something messed up your Acme Client or acme.sh config. I don't think any OPNsense component did this. And the Acme Client plugin will never change a cert ID. So may it was your Ansible, or something else. I don't know.

[skipperTux]

ACME Client and HAProxy have not been installed using Ansible, have been installed manually, roughly following this guide, as I currently do not have scripts for these Plugins.

I also don't get it, the acme.sh command using one path, but in the ACME log the path is different 🤷‍♂️??

[fraenki]

I also don't get it, the acme.sh command using one path, but in the ACME log the path is different?

acme.sh is the tool that handles the actual creation/renewal of certificates. The "ACME Log" contains the raw log messages from acme.sh.

AcmeClient is the OPNsense plugin component, this component only logs to the "System Log".

So the AcmeClient plugin thinks that your cert ID is 634c119619e747.53710732, but the acme.sh tool thinks it's 634c116f6097a2.72834012. Like I said, there's no way that the plugin could mess it up this way. That's all I know.

[fraenki]

So the AcmeClient plugin thinks that your cert ID is 634c119619e747.53710732, but the acme.sh tool thinks it's 634c116f6097a2.72834012. Like I said, there's no way that the plugin could mess it up this way. That's all I know.

You may want to check the acme.sh parts for your cert:

ls -l /var/etc/acme-client/home/CERTNAME/

And maybe also review the contents of the cert config:

cat /var/etc/acme-client/home/CERTNAME/CERTNAME.conf

[fraenki]

Oh wait, did you create two (or more) certificates with the exact same name?
I also think the following flow of events might confuse acme.sh: create cert, issue, remove from GUI, create new cert with same name, issue...

[skipperTux]

I think you have caught me with this 😮, if you mean by exact same name the certificate Common Name. I first setup everything using Let's Encrypt Staging (Test CA), but using the intended final domains (e.g. *.example.org and *.sub.example.org). After that I switched to production but using the same common names. I did not find any other way to test my setup, but I could not give the certificates an id-name, independent from the intended domain (= common name).
With regards to your checkings, the CERTNAME.conf is pointing to this value 634c116f6097a2.72834012, so the value from the ACME Log / acme.sh. Maybe the plugin is still connected to the Staging CA CERTNAME.

Is this setup for Test and Prod CA wrong? Any idea for a better setup (without having two different domains) and how to fix this setup?

[fraenki]

That's actually a limitation in the way we use acme.sh: you cannot have two certificates with the exact same common name.

I think it is possible to mitigate this limitation in the Acme Client plugin, but it's not trivial and will require code changes and extensive testing. This isn't something that will be ready soon. I'll probably need a lot time for this, so no ETA.

However, even when this mitigation is implemented, it will be unable to fix what's currently broken.

As a quick fix you might try to remove the certificate(s) from Acme Client and OPNsense Trust and create/issue a new certificate. It should update the broken acme.sh configuration... but be aware that's just guessing on my side. I first need to figure out how to reliably reproduce this issue to know how to properly fix it.

[skipperTux]

(Sorry for the late reply, I was locked out of Let's Encrypt because of limits.)

I can confirm the following steps work to fix an existing duplicate Common Name issue:

1. Disable (or remove) certificates with duplicate names in Services: ACME Client: Certificates. Make sure all enabled certificates have a unique Common Name. In my case I disabled the staging certificates for the same Common Name, see screenshot.
   
2. Except for the self-signed Web GUI TLS certificate, delete all duplicate Common Name certificates from System: Trust: Certificates. If one of those certificates is used as the Web GUI SSL Certificate in System: Settings: Administration, you have to temporarily switch to the OPNsense self-signed certificate.
3. Restart ACME client and HAProxy services (better safe than sorry).
4. Now you can either Run automations or Issue or renew certificate(s) in Services: ACME Client: Certificates. Make sure you did not hit any Let's Encrypt limits before renewal.
5. Wait for the ACME client to finish, check the Log Files in Services: ACME Client: Log Files and check the Certificates in System: Trust: Certificates.
6. Reassign the new certificate(s), like the Web GUI SSL Certificate, if you have temporarily switched in step 2, or in HAProxy service.

Make sure you never have duplicate Common Names when ACME client is running. If you want to switch to a same Common Name certificate (like staging), I assume you have to redo all above steps (not confirmed).

[fraenki]

The upcoming os-acme-client 4.0 will officially support duplicate common names.
However, it cannot fix what is already broken, so if someone currently has a broken common names configuration, these certificates probably need to be reset and re-issued (after upgrading to os-acme-client 4.0).