[davidgerard]

We are switching our Comodo certs over to Let's Encrypt because certain old Android versions we have to support work with LE certs but not with Comodo. Particularly important for APIs.

The 90 day expiry is a bit of a faff, but we've mostly automated it using acme.sh and automated DNS edits, and now we just need load balancer access (we just moved to new hosts). LE is a godsend and fully up to commercial use in our experience.

After this, there is no way on earth we're giving Comodo money again. I would rather pay Thawte than these bozos.

[technion]

I've dealt with this issue for years.

Comodo certs have two possible chains. If you want to be supported by older Android (and older iOS) devices, you needed to configure your server to hand out the longer of the chains. When you buy a cert, this is not the chain they will recommend.

This is easy under Linux if you can find the right certs, a huge PITA if you're on IIS.

They do an incredibly poor job of documenting this or informing their support on how to address it.

[davidgerard]

We switched to Let's Encrypt literally because of this, so that's a direct penalty for their stupidity on this one ;-)

Do you know a writeup anywhere of the cert chain issue? (I ask for idle amusement, no way we're going back to them.)

Oh, and when I say "fully up to commercial use", we plan to use LE certs for our dev instances too (so we're SSL at all stages of development).

[technion]

No write up anywhere that I ever found. The best investigative tool is the SSLLabs SSL test, which will show you both possible paths from the cert. By looking at which certificates that test shows the server provided, you can divine which path things are going to take.

If you find yourself landing at a root CA which is newer and not trusted by as many devices, those devices won't intelligently realise it's cross-signed, unless you switch the certs the server offers to send them up that path.