Multiple wildcard certificates

Help
1

I had already a wildcard certificate for *.pxtr.de , and a fixed one for pxtr.de .
As I've noticed, that the wildcard certificate is valid only for a single level, and I want to use a second level too - *.museum.pxtr.de - , I've created the command below and run it. It finished successfully, and created a new certificate, but no wildcard certificate at all - instead all of the used subdomains were listed individually. For me it has the problem, that I am planning to use new subdomains - so instead of not dealing with the certificates when creating a new subdomain I need to run certbot each time - and with a manual dns validation method it is cumbersome.

My domain is: pxtr.de , *.pxtr.de , *.museum.pxtr.de

I ran this command: certbot certonly --manual --preferred-challenges=dns --email -redacted-@gmail.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.pxtr.de -d *.museum.pxtr.de

It produced this output: -- finished successfully --

My web server is (include version): Apache2 2.4.7

The operating system my web server runs on is (include version): Ubuntu 14.04.6

My hosting provider, if applicable, is: contabo

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): certbot 0.31.0

2

Can you describe this in more detail? Because the cert has the two wildcard names that you showed on the command line. What else were you expecting?

Also, you probably still want to list the apex name pxtr.de too if you want HTTPS to work for that name too.

See the Subject Alternative Name: crt.sh | 15993163453

And, this is ancient version almost 6 years old. It is current 3.0.1

See: https://certbot.eff.org

2 Likes
3

No it didn't. The link to crt.sh (the cert you've generated today) from Mike shows:

            X509v3 Subject Alternative Name: 
                DNS:*.museum.pxtr.de
                DNS:*.pxtr.de

So it surely is a wildcard certificate :slight_smile:

2 Likes
4

Osiris has right.

Sorry guys, as it looks like, I've made a stupid error checking not the correct certificate, when I was searching for the reason of a problem (typo in the apache config). This whole post can be deleted, because the starting point is not true: certbot created really the two wildcard domain certificate.

( Maybe 0.31.0 is an ancient version, but apt-get says on Ubuntu 14, this is the last version. And I do not want to upgrade for a newer Ubuntu, because we have a legacy PHP5 site. Perhaps with Docker I can make the step to an actual Linux ... but it still costs work for me. )

5

I hope you're paying to get Expanded Security MaintenanceLegacy Support for Ubuntu 14.04? As the Standard Support ended almost 5 years ago. Unless you can subscribe to Ubuntu Pro for free for personal use.. Nevermind free for personal use, Legacy Support is a payed service and as ESM ended in April last year, you'd need that.

1 Like
6

Your pre-wildcard certs had your apex name in it. But, your wildcard does not. You should probably request a new cert with the two wildcard names and your apex.

The *.pxtr.de only matches subdomains of it (any values in place of *) and not pxtr.de itself

1 Like
7

I had an other, old certificate covering my pxtr.de (and a few of other domains) from the time I did not knew a wildcard domain name will be needed. The renewal runs without manual task, so it did not bothered me the have multiple certs, but I just extended my new certificate to cover pxtr.de too, being able to simplify my apache ssl config.

1 Like
8

I expect it'll be a pain, but you should really move to supported version of Ubuntu, and move your PHP5 site to Docker.

https://hub.docker.com/_/php/tags?name=5.

1 Like
9

If you are sure there are no references to those older certs that have auto-renew you should delete them from Certbot's system so they don't continue to renew.

This probably works even for your ancient version

sudo certbot delete --cert-name X

Where X is the cert name from

sudo certbot certificates
10

Thank you for the information ! Now I know, why my provider raised the price for my virtual server with that explanation: the operating system is too old, they do not provide it for new installations.

11

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