Please support wildcard certificates

Issuance Policy
64

You need 2 ssl certificates one for RSA and one for ECC keys. But not many web servers support dual SSL certificates - Nginx doesn't at least - I did post an explanation on my forums https://community.centminmod.com/posts/4870/

BoringSSL supports equal preference ssl cipher/ssl certs but not many web servers use BoringSSL as opposed to OpenSSL or LibreSSL.

Wikimedia foundation has patched Nginx for multple SSL certificate support see Multiple certificate support revisited. So hoping Nginx would merge such patches eventually :slight_smile:

We've forward-ported Filipe's Apr 27 variant onto Debian's 1.9.3-1
package. Most of the porting was trivial (offsets / whitespace /
etc). There were a couple of slightly more substantial issues around
the newer OCSP Stapling valid-timestamp checking, and the porting of
the general multi-cert work to the newer stream modules. The
ported/updated variant of the patches we're running is available here
in our repo:

https://github.com/wikimedia/operations-software-nginx/blob/wmf-1.9.3-1/debian/patches/

Our configuration uses a pair of otherwise-identical RSA and ECDSA
keys and an external OCSP ssl_stapling_file (certs are from
GlobalSign, chain/OCSP info is identical in the pair). Our typical
relevant config fragment in the server section looks like this:

ssl_certificate /etc/ssl/localcerts/ecc-uni.wikimedia.org.chained.crt;
ssl_certificate_key /etc/ssl/private/ecc-uni.wikimedia.org.key;
ssl_certificate /etc/ssl/localcerts/uni.wikimedia.org.chained.crt;
ssl_certificate_key /etc/ssl/private/uni.wikimedia.org.key;
ssl_stapling on;
ssl_stapling_file /var/cache/ocsp/unified.ocsp;

66

Wanted to follow-up with the use case I mentioned earlier, Sandstorm. They recently took the advice of some here and implemented HTTPS wildcard support to go along with their free DNS service. This means that folks using the Sandstorm DNS service (sandcats.io) no longer need to pay for wildcard certificates in order to have certificates trusted by most browsers. They went with GlobalSign for their certs.

This doesn’t solve the problem for folks using Sandstorm with their own DNS service or a DNS service other than sandcats.io. So, it’s still really helpful for folks to have access to free wildcard certificates.

Hopefully, one day in the future, Let’s Encrypt will offer this.

2 Likes
67

+100 for wildcard support.

68

Reminder: Please don’t add comments just saying “+1.” They make it harder to find the more substantive posts in this thread.

6 Likes
69

Why not just click the :heart: (like) button on the original post? It would also stop flood of email from this thread.

Oh, I forgot to say +1 too in case I didn’t say it earlier.

1 Like
70

Plus 1 Me too Please Support

71

I’m going to close this thread to stop all of the +1 replies. The Let’s Encrypt project is aware that people would like us to support wildcard certificates and that some people have use cases that can’t be satisfied without them.

I believe the technical discussion related to how this would work if any ACME CA decided to try to support it is mostly in the ACME WG at the IETF, so people are welcome to talk about the technical questions there. https://datatracker.ietf.org/wg/acme/documents/ (Note that the ACME WG doesn’t decide issuance policy for Let’s Encrypt; what could be on-topic for them is a discussion of how wildcard-related verifications could happen at a technical level.)

If anyone has a different issuance policy question, or a question or suggestion about workarounds for people who can’t get wildcard certificates, please start a new thread to discuss it. Starting a new thread in the future is also appropriate if Let’s Encrypt makes any future announcement about this topic.

16 Likes