Please support wildcard certificates


#51

Okay, yes you’re right - multiple-domains should also does this.

Yeah, DNS queries are a completely different thing of course. And yes DNSCrypt is a really nice system.


#52

Again, the critical part is “securing a HTTP/2 (h2) connection” - the h2 spec allows you to send requests for all domains listed in the certificate, so the network viewers can only see the first domain you connected to in the clear.


#53

+1 for wildcard support


#54

+1 for wildcard support.


#55

Hi folks, could you please stop posting “+1” responses to this thread? We’re aware that there are thousands of prospective users who would like wildcard certificates and that some of them have use cases that can’t be satisfied without wildcard certificates.

Nonetheless, we are unfortunately unable to support wildcard certificates, at least at the outset, and seeing additional “+1” replies won’t change that. I’m sorry for the inconvenience.


#56

@eva2000 which product? GoDaddy Standard Wildcard SSL? I don’t see any other that is under $55 other than that one.


#57

GoGetSSL resellers get an additional brand called GGSSL standard and wildcard SSL certificates which are essentially Comodo signed and backed SSL certs

GGSSL wildcard on centminmod.com

testssl centminmod.com:443

TLS server extensions        renegotiation info, EC point formats, session ticket, status request
 Session Tickets RFC 5077     3600 seconds
 Server key size              2048 bit
 Signature Algorithm          SHA256 with RSA
 Fingerprint / Serial         SHA1 8CCB5CAA6066F2321A6FE8ED37920B7687CFBE39 / 623CBC1C62FD9C08BD83C9F033B009C8
                              SHA256 F9B041F7F6ACB1503FB68592B7F0B972D47683402DA2A5D30BAFCF9B70405E88
 Common Name (CN)             *.centminmod.com (wildcard certificate match) (CN in response to request w/o SNI: *.centminmod.com)
 subjectAltName (SAN)         *.centminmod.com centminmod.com 
 Issuer                       COMODO RSA Domain Validation Secure Server CA (COMODO CA Limited from GB)
 EV cert (experimental)       no 
 Certificate Expiration       >= 60 days (2014-08-14 00:00 --> 2017-08-13 23:59 +0000)
 # of certificates provided   3
 Certificate Revocation List  http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl
 OCSP URI                     http://ocsp.comodoca.com
 OCSP stapling                offered

Short certificate period - no useable on multi server scenario
#58

Came here looking for this. Absolutely a great reason that could save libraries $$$


#59

+1 for this.

It’s a whole different dimension for me.
I’m not just managing websites and it’s subdomains, I’ve got different domains from different projects, sometimes with different people in the lead to manage (which prefer to keep security and such to people that know their stuff), so using wildcards comes in as second nature to keep me sane…

Even though it may sound pretty large scale it’s just using the otherwise unused server resources to help some people. (Many small things count up with the time)

So it’s a requirement for me to even consider switching to this service.
Though the basic idea is really interesting and I can’t wait to see what’ll happen once it’s out in the wild so kudos for providing this in the first place.


#61

Does anybody know where to find compiled list what features each CA supports exactly?

I’ve checked with GoDaddy few days ago:
GD support RSA keys only, no ECC.
GD cannot combine wildcard and UC/SAN into single certificate. It might be rarely needed, but still.
GD won’t allow certs with different key OR different key types for a “single purchase”. We do use ECC + RSA certs as a F5 hybrid certificate.
All above is provided by DigiCert, for the premium price of course.


#62

for ECC 256bit SSL certs, only know of Comodo (including GoGetSSL GGSSL brand SSL certs) and Symantec ECC offered SSL certificates that support them

so if you want ECC 256bit SSL now, Comodo SSL certs is best bet - it’s what i run for sslspdy.com with GGSSL/Comodo wildcard https://sslspdy.com/


#63

eva2000,
Thanks for your answer!
Could you clarify a bit, please:
For you current certificate purchase for sslspdy.com domain, can CA issue 2 certificates with RSA and EC keys, active at the same time?
Or you have to buy them separately?


#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 http://forum.nginx.org/read.php?29,261089. 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.


#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.


#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.


#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.


Short certificate period - no useable on multi server scenario
closed #72