The author said, he randomizes between the 4 free-of-charge SSL provides because of availability and reliability.
What me would interest, if it would be possible cross-sign the certificates by all of those 4 and automate this?
What me would interest, if it would be possible cross-sign the certificates by all of those 4 and automate this?
You will often see people describing the sequence of events something like "I send them this CSR and then the CA signs it" but that's not really what happens at all. The CA is obliged to construct a to-be-signed-Certificate (tbsCertificate) of their own choosing, incorporating only information they're actually happy to stand behind, and with a largely random serial number at the start.
The serial number is because X.509 doesn't have a nonce component, serial numbers are very near the start of the document so it would likely be impossible (using known techniques) to collide a certificate hash (even a known broken one like MD5) so long as this number is very random and chosen by the CA not the subscriber.
The constraint on information in the certificate (e.g. Subject information) is because the CA is signing the entire document. Relying Parties have no reason to assume that a certificate for "Johnny Poopy Pants" was actually not issued based on the CA believing this is really "Johnny Poopy Pants" but instead just because it also mentions the DNS name some.cheap-server.example and the subscriber does control some.cheap-server.example. So, any claims of information about the Subject that aren't being warranted by the CA are not included in the certificate. You can send Let's Encrypt a CSR saying your company name, email address, mailing address of the head office, a logo, whatever, it just gets ignored and Let's Encrypt only care about the DNS names you asked for, those are all that will be in the certificate.
Cross signed roots work by offering multiple certificates for the same key: you can use a self-signed root (from your trust store) or an intermediate signed by a different issuer, or if your validating stack is really competent, you can send multiple intermediates and the validator will check if any of them chain to an acceptable root.
But, the leaf (or end-entity) cert MUST be the first certificate sent, and only one certificate can be first, so there's no optionality there.
If CAs would be willing to sign limited scope intermediates (and if limited scope intermediates were widely usable), you could get your intermediate widely signed and have your leaf certificate signed by that, and include multiple chains from your intermediate. But that would take you from two certs (leaf + CA intermediate) to one + 2N certs (leaf + (your intermediate signed by CA + CA intermediate) * each CA) and all of that would add up to increase the handshake size and slow down initial communication.
It might be nice in some situations, but it's also costly, and support is iffy if you stray outside browsers.