4 ms·

No, it doesn't. Lets Encrypt certs are equivalent to self-signed certs. No hassle ==> broken shit.

unethical_ban 11y ago
No, you are incorrect. At the moment, their certs are cross-signed, and I have tested my site with multiple browsers. It works.
- thehairyone 11y ago
  The cross sign is too far up the chain. If you cross sign a self-signed cert what do you get? A Let's Encrypt Cert. Domain Ownership is not the same as file ownership.
  - pfg 11y ago
    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.
  - thehairyone 11y ago
    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.
      - 11y ago
slachterman 11y ago
I don't think that's correct per https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/ 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.
ceejayoz 11y ago
> Lets Encrypt certs are equivalent to self-signed certs. This is entirely false.
- thehairyone 11y ago
  Oh yeah! sure... what exactly ensures that the DV cert is a DV cert?
  - deleted 11y ago
    [deleted]
  - icebraining 11y ago
    what exactly ensures that the DV cert is a DV cert? The fact that IdenTrust says it's a DV cert, and browsers trust its claims.
detaro 11y ago
You might want to share a few more details if you want those claims to be taken seriously.

No, you are incorrect. At the moment, their certs are cross-signed, and I have tested my site with multiple browsers. It works.

thehairyone 11y ago
The cross sign is too far up the chain. If you cross sign a self-signed cert what do you get? A Let's Encrypt Cert. Domain Ownership is not the same as file ownership.
- pfg 11y ago
  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.
- thehairyone 11y ago
  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.
    - 11y ago

slachterman 11y ago

I don't think that's correct per https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/ 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.

ceejayoz 11y ago

> Lets Encrypt certs are equivalent to self-signed certs. This is entirely false.

thehairyone 11y ago
Oh yeah! sure... what exactly ensures that the DV cert is a DV cert?
- deleted 11y ago
  [deleted]
- icebraining 11y ago
  what exactly ensures that the DV cert is a DV cert? The fact that IdenTrust says it's a DV cert, and browsers trust its claims.

detaro 11y ago

You might want to share a few more details if you want those claims to be taken seriously.