3 ms·

Of course the cross signed cert works! That not the point. The cross signature is worthless if the signed cert beneath it is self-signed. If Identrust cross

Of course the cross signed cert works! That not the point. The cross signature is worthless if the signed cert beneath it is self-signed. If Identrust cross signed self signed certs, the self signed cert would be trusted too... and it would "work" in all browsers... Coly Tarry Frap Tarts! you're daft. Here try this: 1. Setup a domain with an MX record that points off domain and a dmarc p=reject record... 2. Try to get a cert from any CA other than Lets Encrypt without answering any emails sent to the off domain MX. ... Then... install Lets Encrypt... bam-o! Cert heaven! It's self-gawd-damn-fing-signed.

pfg 11y ago
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. [1]: https://crt.sh/?caid=7395 https://crt.sh/?caid=7395 [2]: soon! [3]: At least one other CA (WoSign) does this, there are probably others I'm not aware of.
- deleted 11y ago
  [deleted]
thehairyone 11y ago
@pfg: I know exactly how CAs work. I've built several. 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.
- jcrites 11y ago
  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. If you've been involved in a CA, then you should be familiar with the CAB forum baseline requirements for Verification Practices. https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf > 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 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.
- pfg 11y ago
  I just signed up using my personal gmail address and was offered this option to verify domain ownership: http://puu.sh/mB373/62a963d896.png http://puu.sh/mB373/62a963d896.png The file contains a random token. This is essentially the same solution Let's Encrypt offers (among others).
- fps 11y ago
  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 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 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.

pfg 11y ago

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. [1]: https://crt.sh/?caid=7395 https://crt.sh/?caid=7395 [2]: soon! [3]: At least one other CA (WoSign) does this, there are probably others I'm not aware of.

deleted 11y ago
[deleted]

thehairyone 11y ago

@pfg: I know exactly how CAs work. I've built several. 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.

jcrites 11y ago
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. If you've been involved in a CA, then you should be familiar with the CAB forum baseline requirements for Verification Practices. https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf > 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 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.
pfg 11y ago
I just signed up using my personal gmail address and was offered this option to verify domain ownership: http://puu.sh/mB373/62a963d896.png http://puu.sh/mB373/62a963d896.png The file contains a random token. This is essentially the same solution Let's Encrypt offers (among others).
fps 11y ago
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 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 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.