4 ms·

Domains don't have to be externally accessible, they just can't be internal names (i.e. "made-up" domain names that you do not actually own), which is true for

by pfg 10y ago

Domains don't have to be externally accessible, they just can't be internal names (i.e. "made-up" domain names that you do not actually own), which is true for all public CAs. The DNS-01 challenge type does not require that you open any port, you just need the ability to create TXT records.

icebraining 10y ago
Ah, right, forgot about DNS validation.
newman314 10y ago
Unfortunately, there are still idiots (sorry, I feel strongly about this) that somehow thought it was a good idea to use "internal" names. Now I face an uphill battle to get things corrected. ARGH.
kuschku 10y ago
Well, all domains are internal names, just in the root space . Not supporting internal domains is understandable, but requiring https for internal things is an issue.
- pfg 10y ago
  I'm not sure what your last sentence is referring to. Who or what is requiring https for internal things?
  - kuschku 10y ago
    For example, Chrome disables several JS features and APIs on non-https pages.
    - pfg 10y ago
      Oh, I thought you were referring to something on Let's Encrypt's end. For "real" internal names, internal CAs sound like the best option, and would work just fine with what browsers call "powerful features." For anything else, Let's Encrypt would work.
      - kuschku 10y ago
        Except, you can't use internal CAs anymore on Android devices. Adding CAs to those is now impossible since Nougat.
        pfg 10y ago
        AFAIK that is only relevant for apps. It is still possible to import CAs for browser traffic, for example, and it's still possible to opt-in to trusting custom CAs as an app. So this is only really a problem for non-browser apps that a) need to communicate with internal domains and b) are not within the control of the organization the internal domain belongs to. I'm sure use-cases like that exist, but they ought to be exceedingly rare.
        kuschku 10y ago
        Well, such use cases are internal email via IMAP with STARTSSL, they are browser traffic with default browsers (those don't allow custom CAs either, you'll likely have to compile a custom build yourself), etc. Basically, if you want to use any app - be it IRCCloud, Slack, Locally-Hosted Google Apps for big businesses as a box, etc locally, with a custom CA, you have to customly modify every single one of those apps, or you have to buy a CA. That's a great fucking piece of shit.
        pfg 10y ago
        > Well, such use cases are internal email via IMAP with STARTSSL, they are browser traffic with default browsers (those don't allow custom CAs either, you'll likely have to compile a custom build yourself), etc. Do you have a source for this? Whether non-standard CAs are accepted is up to the individual apps. Android N still has the ability to install custom root certificates. I haven't seen an announcement regarding, for example, the standard mail client or Chrome for Android. > Basically, if you want to use any app - be it IRCCloud, Slack, Locally-Hosted Google Apps for big businesses as a box, etc locally, with a custom CA, you have to customly modify every single one of those apps, or you have to buy a CA. "Buy a CA"? There's no publicly-trusted CA that will issue certificates for internal domains, period. Just stop using internal names for this purpose and you're fine. You can get domains and DNS hosting for a total of $ 0.00, so that's not a valid argument in my book. > That's a great fucking piece of shit. That's a security trade-off that's meant to help protect regular users while inconveniencing a small number of organizations that chose to still use internal names while ignoring many warnings that this is not a best practice, and who are now unable to get publicly-trusted certificates for these domains.
voltagex_ 10y ago
When I last looked at the DNS-01 challenge type, I couldn't work out how to make it work with my DNS provider, Gandi. How does the DNS challenge work with the delay in propagation of new records?
- pfg 10y ago
  lego seems to have a plugin for Gandi's DNS API[1]. Let's Encrypt always sends DNS queries to the domain's authoritative DNS server and doesn't cache any results, so as soon as your authoritative DNS server has the record, you're good. [1]: https://github.com/xenolf/lego/tree/master/providers/dns/gandi https://github.com/xenolf/lego/tree/master/providers/dns/gan...
  - voltagex_ 10y ago
    Aha! The project that was missing Gandi API support was https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon - but it now has support. I'll look into lego, thanks.

by pfg 10y ago

icebraining 10y ago

Ah, right, forgot about DNS validation.

newman314 10y ago

Unfortunately, there are still idiots (sorry, I feel strongly about this) that somehow thought it was a good idea to use "internal" names. Now I face an uphill battle to get things corrected. ARGH.

kuschku 10y ago

Well, all domains are internal names, just in the root space . Not supporting internal domains is understandable, but requiring https for internal things is an issue.

pfg 10y ago
I'm not sure what your last sentence is referring to. Who or what is requiring https for internal things?
- kuschku 10y ago
  For example, Chrome disables several JS features and APIs on non-https pages.
  - pfg 10y ago
    Oh, I thought you were referring to something on Let's Encrypt's end. For "real" internal names, internal CAs sound like the best option, and would work just fine with what browsers call "powerful features." For anything else, Let's Encrypt would work.
    - kuschku 10y ago
      Except, you can't use internal CAs anymore on Android devices. Adding CAs to those is now impossible since Nougat.
      - pfg 10y ago
        AFAIK that is only relevant for apps. It is still possible to import CAs for browser traffic, for example, and it's still possible to opt-in to trusting custom CAs as an app. So this is only really a problem for non-browser apps that a) need to communicate with internal domains and b) are not within the control of the organization the internal domain belongs to. I'm sure use-cases like that exist, but they ought to be exceedingly rare.
        kuschku 10y ago
        Well, such use cases are internal email via IMAP with STARTSSL, they are browser traffic with default browsers (those don't allow custom CAs either, you'll likely have to compile a custom build yourself), etc. Basically, if you want to use any app - be it IRCCloud, Slack, Locally-Hosted Google Apps for big businesses as a box, etc locally, with a custom CA, you have to customly modify every single one of those apps, or you have to buy a CA. That's a great fucking piece of shit.
        pfg 10y ago
        > Well, such use cases are internal email via IMAP with STARTSSL, they are browser traffic with default browsers (those don't allow custom CAs either, you'll likely have to compile a custom build yourself), etc. Do you have a source for this? Whether non-standard CAs are accepted is up to the individual apps. Android N still has the ability to install custom root certificates. I haven't seen an announcement regarding, for example, the standard mail client or Chrome for Android. > Basically, if you want to use any app - be it IRCCloud, Slack, Locally-Hosted Google Apps for big businesses as a box, etc locally, with a custom CA, you have to customly modify every single one of those apps, or you have to buy a CA. "Buy a CA"? There's no publicly-trusted CA that will issue certificates for internal domains, period. Just stop using internal names for this purpose and you're fine. You can get domains and DNS hosting for a total of $ 0.00, so that's not a valid argument in my book. > That's a great fucking piece of shit. That's a security trade-off that's meant to help protect regular users while inconveniencing a small number of organizations that chose to still use internal names while ignoring many warnings that this is not a best practice, and who are now unable to get publicly-trusted certificates for these domains.

voltagex_ 10y ago

When I last looked at the DNS-01 challenge type, I couldn't work out how to make it work with my DNS provider, Gandi. How does the DNS challenge work with the delay in propagation of new records?

pfg 10y ago
lego seems to have a plugin for Gandi's DNS API[1]. Let's Encrypt always sends DNS queries to the domain's authoritative DNS server and doesn't cache any results, so as soon as your authoritative DNS server has the record, you're good. [1]: https://github.com/xenolf/lego/tree/master/providers/dns/gandi https://github.com/xenolf/lego/tree/master/providers/dns/gan...
- voltagex_ 10y ago
  Aha! The project that was missing Gandi API support was https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon - but it now has support. I'll look into lego, thanks.