Cert renewal works for www.somedom or somedom, but not for both

Help
1

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: nepustil.net

I ran this command: service apache24 restart

It produced this output: OK

My web server is (include version): apache2-2.4.57

The operating system my web server runs on is (include version): FreeBSD 13.2-REL-p2

My hosting provider, if applicable, is: nepustil

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): mod_md from apache

2

The problem is: mod_md renews either www.nepustil.net or nepustil.net, but not both. why ?

3

Can you show your Apache config MDomain statement(s) and related VirtualHost?

The example of one is here: mod_md - Apache HTTP Server Version 2.4

You should use 3 backticks before and after the output to ensure all the tags are shown like this:

```
apache config
```

3 Likes
5 
[...]
<IfModule md_module>
  MDBaseServer off
  MDDriveMode auto
  MDCertificateProtocol ACME
  MDCertificateAuthority https://acme-v02.api.letsencrypt.org/directory
  MDCertificateAgreement https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
  MDPrivateKeys RSA 4096
  MDRequireHttps permanent
  MDStoreDir /usr/local/etc/apache24/certs/
  MDomain www.nepustil.net
  MDomain nepustil.net
[...more domains...]
</IfModule>
[...]
<VirtualHost 212.71.215.240:443 [2001:14f8:10:3::1:0]:443>
ServerName nepustil.net:443
DocumentRoot /serv/www/nepustil.net/data
ServerAdmin webmaster@nepustil.net

SSLEngine on
SSLHonorCipherOrder On
SSLCompression Off
[...]
</VirtualHost>

<VirtualHost nepustil.net:80>
ServerName nepustil.net:80
RedirectPermanent / https://nepustil.net/

</VirtualHost>

<VirtualHost www.nepustil.net:80>
ServerName www.nepustil.net:80
RedirectPermanent / https://nepustil.net/

</VirtualHost>

<VirtualHost 212.71.215.240:443 [2001:14f8:10:3::1:0]:443>
ServerName www.nepustil.net:443
RedirectPermanent / https://nepustil.net/

SSLEngine on
SSLHonorCipherOrder On
SSLCompression Off
[...]
</VirtualHost>

<VirtualHost 212.71.215.240:80 [2001:14f8:10:3::1:0]:80>
ServerName nepustil.net:80
RedirectPermanent / https://nepustil.net/

</VirtualHost>
6

Is there some specific reason you are using domain names and IP addresses in your VirtualHost statement. Because that can easily cause problems especially when mixing the forms.

It is rare to need to use that form these days so I'll assume you don't need them.

You also have the same ServerName nepustil.net listed twice. Is that a mistake because it looks like it could cause problems.

Also, you don't usually use a port with the ServerName line when it is stated in the VirtualHost line.

I don't know if this is causing the problems with mod_md. I would start by simplifying your VirtualHosts to look like below and try again. You may need to clear out the mod_md data to reset it.

Replace all of what you showed above with below. Note the last VirtualHost was deleted since it is a duplicate of an earlier one when using this cleaner syntax

<VirtualHost *:443>
ServerName nepustil.net
DocumentRoot /serv/www/nepustil.net/data
ServerAdmin webmaster@nepustil.net

SSLEngine on
SSLHonorCipherOrder On
SSLCompression Off
[...]
</VirtualHost>

<VirtualHost *:80>
ServerName nepustil.net
RedirectPermanent / https://nepustil.net/

</VirtualHost>

<VirtualHost *:80>
ServerName www.nepustil.net
RedirectPermanent / https://nepustil.net/

</VirtualHost>

<VirtualHost *:443>
ServerName www.nepustil.net:443
RedirectPermanent / https://nepustil.net/

SSLEngine on
SSLHonorCipherOrder On
SSLCompression Off
[...]
</VirtualHost>
2 Likes
7

Yes, there are other Vhosts for other domains on other IPs on the same box.

So a <*:443> would, from what I understand, fail to work.

8

During an apache restart, this is logged:

[Thu Jun 06 09:26:30.519324 2024] [md:debug] [pid 15933] mod_md.c(555): AH10169: www.nepustil.net: https server_rec for www.nepustil.net does not have protocol acme-tls/1 enabled
[Thu Jun 06 09:26:30.519559 2024] [md:debug] [pid 15933] md_reg.c(256): md{www.nepustil.net}: certificate(0) is ok
[Thu Jun 06 09:26:30.519572 2024] [md:debug] [pid 15933] md_reg.c(941): loading md www.nepustil.net
[Thu Jun 06 09:26:30.519624 2024] [md:debug] [pid 15933] md_reg.c(943): loaded md www.nepustil.net
[Thu Jun 06 09:26:30.519636 2024] [md:debug] [pid 15933] md_reg.c(987): sync MDs, finish done
[Thu Jun 06 09:26:30.519645 2024] [md:debug] [pid 15933] mod_md.c(555): AH10169: nepustil.net: https server_rec for nepustil.net does not have protocol acme-tls/1 enabled
[Thu Jun 06 09:26:30.519779 2024] [md:debug] [pid 15933] md_reg.c(256): md{nepustil.net}: certificate(0) is ok
[Thu Jun 06 09:26:30.519792 2024] [md:debug] [pid 15933] md_reg.c(941): loading md nepustil.net
[Thu Jun 06 09:26:30.519834 2024] [md:debug] [pid 15933] md_reg.c(943): loaded md nepustil.net
[Thu Jun 06 09:26:30.519844 2024] [md:debug] [pid 15933] md_reg.c(987): sync MDs, finish done

So it seems mod_md checks the cert files, but does not act on it.

But the cert files for www.nepustil.net are from 2023, so while mod_md reads it, it does not see them as required for renewal. If I move them aside, fallback-*pem files are created, but again no need to renew them seems to be seen by mod_md.

9

That particular server has mod_md 2.4.21, and the update has to wait until one of the users approves the update to a more recent apache/mod_md 8-(

10

We got the go-ahead to update, are now at the latest mod_md, problem still happens.

11

ah, shucks, it's 2.4.25 from the freebsd ports, and 2.4.26 upstream. Changelog does not seem to mention issues like the one we have.

12

There are cases to use IP addresses in the VirtualHost statement. And, maybe yours is one of those cases. In most cases you leave the IP address off and let the HOST in the URL handle VHost selection (called Name-Based VHosts). For SSL connections SNI is needed but that has been around for a long time.

I still think the above two VHosts are duplicate. Generally you should be consistent throughout all the VirtualHost statements in your Apache. Again, it is possible to mix/match but that is difficult to get right. Very easy to make mistakes that cause considerable problems.

Putting that concern aside and returning to mod_md...

Your base name works as you have a fresh cert for it. The www subdomain of that is the problem. You say they alternate working but I don't see a cert for the www subdomain since about a year ago.

I think your best option is to post the issue on the github were mod_md originated. You might first try this topic GitHub - icing/mod_md: Let's Encrypt (ACME) in Apache httpd which describes how to remove all md managed certs or just one. You could check and carefully remove any related to the www subdomain.

If that doesn't help get it working, post an issue below

2 Likes
13

There's an issue very similar to ours:

1 Like
14

It basically says: If a cert does not renew, remove the related staging//
directory and restart apache. Well, it works, it's still painful.

1 Like
15

Glad you found the answer. The mod_md github is the best place to seek complete resolution of that.

I am curious why removing the staging folder for the failed cert would be a problem. Seems like a pretty easy way to reset.

2 Likes
16

It's not a problem removing it, the problem is that having it prevents a cert from renewal.

We add fixes on top of fixes, and it does not look like it's improving...

2 Likes
17

Sorry to hear that.

You have a complicated Apache configuration.

Just generally my experience says things are more reliable when they are simpler.

3 Likes
18

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