Question Let's Encrypt *Wildcard Certificates

[learning_curve]

Let's Encrypt *Wildcard Certificates were officially released a little while ago and are live

The current status of the associated Plesk Let's Encrypt Extension is clearly stated here (#132)

We asked this question (#135) in order to add a possible "meantime... workaround" type option for Let's Encrypt *Wildcard Certificates until the Plesk Let's Encrypt Extension is upgraded to include them.

But.... There's been no answer to the question, so we've asked it on here instead, in case somebody has already done this / can add more technical data / comments

 

[virtubox]

Let's Encrypt *Wildcard Certificates were officially released a little while ago and are live

The current status of the associated Plesk Let's Encrypt Extension is clearly stated here (#132)

We asked this question (#135) in order to add a possible "meantime... workaround" type option for Let's Encrypt *Wildcard Certificates until the Plesk Let's Encrypt Extension is upgraded to include them.

But.... There's been no answer to the question, so we've asked it on here instead, in case somebody has already done this / can add more technical data / comments

Hello @learning_curve,
at the moment, we use acme.sh (with Cloudflare DNS) to issue Let's Encrypt wildcard certificates, and the Plesk CLI to add them in Plesk.

Steps to setup our certificates :

# issue a wildcard ECC ceritficate with Cloudflare DNS API validation
acme.sh --issue -d yourdomain.tld -d *.yourdomain.tld --dns dns_cf --keylength ec-384 --server https://acme-v02.api.letsencrypt.org/directory

# crerate a new folder for use in production

mkdir -p /etc/nginx/acme.sh/yourdomain.tld

# install the certificate in the folder
# --reloadcmd will be used to reload web servers after cert renewal

acme.sh --install-cert -d yourdomain.tld --ecc \
--cert-file /etc/nginx/acme.sh/yourdomain.tld/cert.pem \
--key-file /etc/nginx/acme.sh/yourdomain.tld/key.pem \
--fullchain-file /etc/nginx/acme.sh/yourdomain.tld/fullchain.pem \
--reloadcmd "systemctl reload nginx.service && systemctl reload apache2.service"

# create the certificate in Plesk

plesk bin certificate --create "yourdomain wildcard LE" -domain yourdomain.tld -cert-file /etc/nginx-acme.sh/yourdomain.tld/cert.pem -key-file /etc/nginx-acme.sh/yourdomain.tld/key.pem -cacert-file /root/.acme.sh/yourdomain.tld_ecc/ca.cer

# assign the certificate

plesk bin certificate --assign-cert  "yourdomain wildcard LE" -domain yourdomain.tld -ip XXX.XXX.XXX.XXX

We have published an article in our knowledgebase about wildcard certificates validation methods and options for nginx, but it's almost the same for Plesk :
How to issue a wildcard SSL certificate with Acme.sh and Nginx - VirtuBox KnowledgeBase

 

[learning_curve]

You've always able to add value and very useful information for us @virtubox This being yet another example! Thanks!

Still not sure why nobody connected to / involved with Plesk has commented on this thread (or the various other threads relating to providing an upgraded sw-cp-server with Onyx 17.8.11) Hopefully they will soon

 

[Sergio Manzi]

There is a feature request for this: Wildcard for Let´s Encrypt

Please vote for it!

 

[learning_curve]

There is a feature request for this: Wildcard for Let´s Encrypt Please vote for it!

????? Did you read the data in the links in the original post properly?

It's ALREADY happening within Plesk via the Extension: The current status of the associated Plesk Let's Encrypt Extension is clearly stated here (#132) So an additional feature request is just duplication of an ongoing active Plesk process surely?

This thread is about an alternative method to the Plesk Extension, because there is no timeframe for this Extension upgrade yet and many people (including us) will need to renew existing *wildcard certificates before the timeframe IS announced and will therefore, be looking for an interim, alternative method. Fortunately @virtubox has already provided an example of one above ^^

 

[Sergio Manzi]

????? Did you read the data in the links in the original post properly?

Of course I did, and I don't see any inconsistency in having:

1. Plesk already working (maybe...) on it
2. A "popular" request for this being implemented

If you consider that it is very unlikely that Plesk can count on unlimited coding resources, a widely supported "uservoice" request can help them correctly prioritize their comprehensibly limited efforts.

So, why the "EEK!"?

 

[Sergio Manzi]

... and certainly I don't see any inconsistency in pointing out to the user voice request for a correct, integrated, mechanism for requesting Let's Encrypt wildcard certificates from the Plesk panel in a thread where the currently available workarounds (hacks, from the point of view of an integrated Plesk panel...) are discussed.

 

[learning_curve]

Of course I did, and I don't see any inconsistency in having:

1. Plesk already working (maybe...) on it
2. A "popular" request for this being implemented

If you consider that it is very unlikely that Plesk can count on unlimited coding resources, a widely supported "uservoice" request can help them correctly prioritize their comprehensibly limited efforts. So, why the "EEK!"?

Good point, but isn't the reality perhaps somewhat different? Plesk are already well aware of the importance of Let's Encrypt *wildcard functionality and this Extension is one of the regular selling points that they use. The updated / upgraded Extension should have already been released (in our opionion). The fact that it's way behind the timeline (when many other providers are not) is awkward and maybe one of the reasons why there's not been any reply on the subject of workarounds from them... yet. We think no amount of additional or popular requests will make Plesk go any faster in this case (sadly). It is what it is!

... and certainly I don't see any inconsistency in pointing out to the user voice request for a correct, integrated, mechanism for requesting Let's Encrypt wildcard certificates from the Plesk panel in a thread where the currently available workarounds (hacks, from the point of view of an integrated Plesk panel...) are discussed.

Again good points. Democratic and fair. However, see above re: isn't the reality perhaps somewhat different? If you're a Plesk user that needs Let's Encrypt *wildcard functionality now or very soon, then workarounds are a vital (and money saving) option.

 

[Sergio Manzi]

We think no amount of additional or popular requests will make Plesk go any faster in this case (sadly). It is what it is!

Don't count me in the "we": I can't be sure it will have any real effect, but I think the best option we have (maybe beside our paying dollars/euro/rubles...) to redress what we see as important issues/lacks is to have our "uservoice" heard.

workarounds are a vital (and money saving) option

Never said anything to the contrary!

 

[learning_curve]

Update...

We were looking for a simple, manual option (workaround - see above ^^) to generate and use a Let's Encrypt Wildcard Certificate as a trial / test on one of the domains we host before we do this for real...

THIS page gives a list of various options, so we chose the Browser option for simplicity and tried two separate options within there (ZeroSSL and SSL for free). No problem with generating valid Let's Encrypt Wildcard Certificates and no problem adding these into Plesk via the /smb/ssl-certificate/list/id/** GUI option. A bit of patience and careful reading en-route seems to be what's required doing it this way. A+ (as before) on QualysSSL and A+ High-Tech Bridge with either of the the new Let's Encrypt Wildcard Certificates and all the other unchanged setup

The next bit is to properly configure this domain's webmail to use the Wildcard Certificates properly....

 

[MarkM]

Hello @learning_curve,
at the moment, we use acme.sh (with Cloudflare DNS) to issue Let's Encrypt wildcard certificates, and the Plesk CLI to add them in Plesk.

Steps to setup our certificates :

# issue a wildcard ECC ceritficate with Cloudflare DNS API validation
acme.sh --issue -d yourdomain.tld -d *.yourdomain.tld --dns dns_cf --keylength ec-384 --server https://acme-v02.api.letsencrypt.org/directory

# crerate a new folder for use in production

mkdir -p /etc/nginx-acme.sh/yourdomain.tld

# install the certificate in the folder
# --reloadcmd will be used to reload web servers after cert renewal

acme.sh --install-cert -d yourdomain.tld --ecc \
--cert-file /etc/nginx/acme.sh/yourdomain.tld/cert.pem \
--key-file /etc/nginx/acme.sh/yourdomain.tld/key.pem \
--fullchain-file /etc/nginx/acme.sh/yourdomain.tld/fullchain.pem \
--reloadcmd "systemctl reload nginx.service && systemctl reload apache2.service"

# create the certificate in Plesk

plesk bin certificate --create "yourdomain wildcard LE" -domain yourdomain.tld -cert-file /etc/nginx-acme.sh/yourdomain.tld/cert.pem -key-file /etc/nginx-acme.sh/yourdomain.tld/key.pem -cacert-file /root/.acme.sh/yourdomain.tld_ecc/ca.cer

# assign the certificate

plesk bin certificate --assign-cert  "yourdomain wildcard LE" -domain yourdomain.tld -ip XXX.XXX.XXX.XXX

We have published an article in our knowledgebase about wildcard certificates validation methods and options for nginx, but it's almost the same for Plesk :
How to issue a wildcard SSL certificate with Acme.sh and Nginx - VirtuBox KnowledgeBase

Just curious, how do you handle renewals? Have you automated it?

 

[learning_curve]

Interesting.... The status of this thread has now been changed to "Answered" (but not by us) which, to be fair, it has been, initially by @virtubox and then by ourselves. However, both methods are different and neither of these methods may suit other Plesk users who use setups are very different than @virtubox and/or our own. Yet despite this..... STILL no real answer from anybody directly related to/with Plesk

 

[virtubox]

Just curious, how do you handle renewals? Have you automated it?

We are still running tests on renewal process, because acme.sh renew automatically all certificates every 30 days, and it provide the ability to reload nginx and apache after the renewal. But we haven't find the best way to update wildcard certs added in Plesk yet.

Interesting.... The status of this thread has now been changed to "Answered" (but not by us) which, to be fair, it has been, initially by @virtubox and then by ourselves. However, both methods are different and neither of these methods may suit other Plesk users who use setups are very different than @virtubox and/or our own. Yet despite this..... STILL no real answer from anybody directly related to/with Plesk

I think it's only related to the best answer feature of the forum.
However, wildcard certificates may require more time to be integrated in Plesk, because acme challenge require to validate the domain with DNS, and that mean it will probably require to use Plesk as DNS server.

So, in most case, it will be easier to use SAN certificates instead of Wildcard certs.

 

[learning_curve]

....However, wildcard certificates may require more time to be integrated in Plesk...

...because acme challenge require to validate the domain with DNS, and that mean it will probably require to use Plesk as DNS server

Yes, fully agree that's it's more complex, but... the point being, lots and lots of other providers are ready now and they were ready on the day the Let's Encrypt Wildcard Certificates were released You've tried one provider, we've tried two others and there's lots more.... As we're all pretty keen Plesk users on this forum, this means, we need to figure out, test and implement our own 'workarounds' until the previoulsy mentioned Extension is finally "ready". Certificates are such an integral part of any decent online presence now, so this situation is not ideal and could / should have been much better timed / implemented - in our opinion FWIW. Still, we both have functional "workarounds' so it could be a lot worse