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