[cranium]

On first sight, with only my knowledge in hand, I do think it is a good idea.

I'm also really interested in knowing if there are issues that could arise or people that annoyed by this kind of automatic conversion and why. What are your thoughts ?

[pfg]

I like to think that this is the right approach, especially for shared hosting environments (which is what this announcement is about, presumably). These site owners already trust OVH to host their sites and to hold the private key for a certificate that is valid for their domains (or rather used to be, until it expired). You'll always find someone who's annoyed by a change or uses a setup that broke because of this (maybe they've pinned to a specific key and ignore expiration dates ...), but that doesn't seem like a common use-case or one that they should aspire to support.

[jedisct1]

If the DNS zones have CAA records that don't include Letsencrypt, clients should refuse using the new certificates.

That would be a problem (provided that CAA working as expected can be qualified as a problem) if the original certificates were still valid. But with expired certificates, there is nothing to lose.

[tialaramex]

No. CAA is an instruction to Certificate Authorities, not an instruction to clients.

Let's Encrypt obeys CAA, if you try to validate for a domain which has a CAA record saying e.g. "Only Symantec may issue for this domain", Let's Encrypt's software will reject the validation. Current Baseline Requirements don't require this of a CA (they're required to document what they do with CAA but most picked "soft fail" ie they will issue but maybe do extra scrutiny) because they feared it would be used somehow in an anti-competitive way.

Client software like Firefox, or Internet Explorer, ignores CAA altogether, as described in the design of CAA.

[ivraatiems]

There are potential security concerns. Suppose Let's Encrypt has a vulnerability other certs don't, or their chain is compromised somehow, this could put people at risk without them knowing it.

It could also complicate matters when renewing certs. If I forget to renew my SSL, it gets replaced with Let's Encrypt, and then I go to renew it and the system gets confused because it looks like I already have a cert from another provider.

In both cases, ample warning and notification will help, and opt-in rather than opt-out will totally alleviate the issues.

[pfg]

> There are potential security concerns. Suppose Let's Encrypt has a vulnerability other certs don't, or their chain is compromised somehow, this could put people at risk without them knowing it.

Could you describe what kind of concerns you're thinking about that would be Let's Encrypt-specific and that would only affect you if you actively use a Let's Encrypt-issued certificate? Generally speaking, a CA key being compromised would affect everyone (unless they use key pinning mechanisms like HPKP, which doesn't get a whole lot of real-world use at the moment, and probably close to zero usage from customers using a shared web hosting plan unless the provider takes care of it). You don't need to actively use a CA to be affected.

> It could also complicate matters when renewing certs. If I forget to renew my SSL, it gets replaced with Let's Encrypt, and then I go to renew it and the system gets confused because it looks like I already have a cert from another provider.

CAs typically don't care about whether you already have a certificate from a different provider (I mean, why would they?), or were you thinking about possible limitations in OVH's system? In that case, this only seems like an issue if they indeed have no way to replace the certificate once it's been enrolled with Let's Encrypt.

[iancarroll]

If Let's Encrypt's chain is compromised, everyone is screwed, not just your site. If _any_ trusted CA is compromised, everyone is screwed, even if they haven't issued a certificate for your site.

There is no way to induce a vulnerability by using an incompetent or malicious CA, provided you generate your own, strong private key. Even issuing an MD5 or SHA-1 certificate cannot actively harm your visitors unless a second preimage attack is developed against the algorithm (in which case, again, everyone is screwed, not just you).

[ivraatiems]

> There is no way to induce a vulnerability by using an incompetent or malicious CA, provided you generate your own, strong private key.

If OVH is doing this automatically, they're the ones generating the keys, right?

[Faaak]

They already have the keys either way: its a shared-hosting environment.