Need Wildcard certificates support | Conflict of interest with CAs?

[HLFH]

Hi,

According to this issue, there are 51 participants that talked about the support - or not - of wildcard certificates with your Let's Encrypt offering.
I believe it's a huge number and we need:

• the research papers that show the evidence in the fact that wildcard certificates weaken TLS security as you said ;
• the explanation of why it's not a conflict of interest negociated with one of your first sponsors - and your strongest partner also - named IdenTrust: was the deal to weaken the security of your offering and don't offer wildcard certificates to avoid the cannibalization of the CA market?

Thanks,
HLFH

[bmw]

@HLFH, we locked #66 because we were unnecessarily aware of the demand for wildcard certificates. Despite locking the issue, I can assure you we haven't forgotten about the demand for this feature.

This repo is for the Let's Encrypt client which follows the ACME protocol which doesn't allow wildcard certificates. Since adding this feature is outside of the scope of the client, I'm closing this issue. Please feel free to follow up with the IETF working group for ACME. You can find more information on their github page.

[MichaelHierweck]

Would someone please explain what ACME Section 6.6 means in this context:

It is up to the server's local policy to decide which names are
acceptable in a certificate, given the authorizations that the server
associates with the client's account key. A server MAY consider a
client authorized for a wildcard domain if it is authorized for the
underlying domain name (without the "*" label).

PR 14 even not merged yet expresses this clearer.

For my understand this would allow LE to authorize a client for a domain (such as: example.com) and issue wildcard certificates (such as: *.example.com) afterwards from the perspective of the ACME specification.

Sounds to my as the lack of wildcard support was related to the server's local policy. If so, please state clearly that LE's policy is (currently) opposed to issuing wildcard certification and stop blaming the ACME WG. :)

If I'm wrong thanks in advance for clarification. :)

[terribleplan]

@bmw Any thoughts on this? Maybe push an update to #66 or even unlock it so people know what's going on? I'm also pinging @jmhodges and @bdaehlie who locked and closed #66 respectively.

I just looked at the spec myself to see if there had been any movement on wildcards, and saw the exact same thing mentioned by @MichaelHierweck (though it is now in Section 6.5 in the latest draft).

Especially considering that this project is no longer just letsencrypt, but now certbot the protocol should be fully supported, and not limited by a single provider who does not follow the spec. Issuance policy is hard, implementing the spec is less so. I assume certbot would just throw up some sort of error message if someone tried to get a wildcard issued by letsencrypt.

As a personal aside I hope that supporting this in the client and pushing the blame properly to the LE server/ca side of things pushes them to allow wildcards, as it would make a few projects I am working on considerably easier.

[bmw]

Personally, I think #66 was resolved properly by pointing people to https://community.letsencrypt.org. As for updating them, I don't think there's anything to be said. The phrase

A server MAY consider a client authorized for a wildcard domain if it is authorized for the underlying domain name (without the "*" label).

is not new and dates back to letsencrypt/acme-spec#166. I was incorrect when I said it wasn't allowed in the ACME spec.

With that said, I created #3233 for tracking the issue of allowing users to request wildcard certificates in the client.