This does not make sense, I'm not sure what you're trying to say. The cross-sign works on all major browsers. Domain validation as practised by Let's Encrypt is in accordance with CA/B Baseline Requirements, and they're not the first CA to offer domain ownership verification via HTTP.
I don't think you understand how the CA system or Let's Encrypt works.
IdenTrust signed Let's Encrypt's intermediate certificate[1] using their trusted root certificate. This intermediate certificate has the CA flag set, so other certificates signed by it are to be trusted too. Intermediate certificates are used by all CAs.
When you run the client on your server, the client submits a CSR to Let's Encrypt's CA server. Let's Encrypt will then verify domain ownership (via HTTP, TLS or DNS[2]). This is done in accordance with CA/B Baseline Requirements, and their practice doesn't differ from other CAs who also offer HTTP[3] or DNS verification. If ownership can be verified, Let's Encrypt will then sign your certificate using their trusted intermediate certificate and send it back to you. It is thus not self-signed, but signed by a trusted CA key.
Wosign does not issue a cert without an email verification.
You can look on their website. There's a nice big box to enter an email address to verify your domain and get the free cert.
Sorry -- "Let's Encrypt" with file verification is not DV.
It's just not DV. Simple really...
And it's gonna break the web. Like netlify up there a few post... using rackspace and "Let's Encrypt". ehh. The first few months will probably be fine and then everything is gonna tank.
Until the smart realize that ACME is fine -- as long as you remove the "or file verification" text.
You seem to think that a certificate authority is obligated to verify ownership of a domain by email (for DV certs). You are mistaken, and that's not the case. The mechanisms supported by Let's Encrypt to authenticate domains are just as good as email verification.
> For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that[] the Applicant[] has control over the FQDN by: [...]
> 4. Communicating with the Domain’s administrator using an email address [...] ‘admin’,
‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ [...] followed by the Domain Name[];
> 6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN
> 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.
The approach used by Let's Encrypt meets this standard (of which email is just one of several options), and the methods they use are just as secure as using email. They specifically offer approach 6. above, which they call Simple HTTP, as well as other approaches that comply with 7. as outlined in https://letsencrypt.github.io/acme-spec/#rfc.section.7 Involving email in the verification process makes certificate provisioning harder to automate and adds no additional security.
I regularly purchase SSL certificates - about 10 or so a year, from gandi. Their validation process is identical to lets encrypt without the automation. All someone needs to get a cert is to control http://yourdomain.tld/<some file> for the brief verification period. A DV cert is automatically issued without an email confirmation of any sort to the domain. I'm certain because I've set up SSL for domains that have no MX records nor any mail servers at the apex record. http://wiki.gandi.net/en/ssl/dcv
DV certs make no promises about the identity of the site operator, just that communications are encrypted. I remember a decade ago buying certificates from Thawte required faxing them business records and ensuring that the D&B records matched the domain registration - while paying $450/year for a cert for a single hostname. The process was through, but wholly unnecessary for the vast majority of sites that weren't directly taking payment information.
Our intermediate is signed by ISRG Root X1. However, since we are a very new certificate authority, ISRG Root X1 is not yet trusted in most browsers. In order to be broadly trusted right away, our intermediate is also cross-signed by another certificate authority, IdenTrust, whose root is already trusted in all major browsers. Specifically, IdenTrust has cross-signed our intermediate using their DST Root CA X3.
