5

I am hoping to clear up some confusion I have regarding the use of Let's Encrypt for an internal site/application. I have not been able to find this information elsewhere.

I want to use Let's Encrypt paired with Certbot to allow the use of SSL on an application.

Questions:

  1. Does Let's Encrypt or Certbot require internet access to perform any part of their job? The application will need to be able to run normally even if internet access is down. From what I can gather the only part that requires internet connectivity is for generating new certs when the 90 day period is drawing to an end.
  2. Let's Encrypt requires a valid domain. Per their website "for any server that uses a domain name, like web servers, mail servers,...". I'm rather ignorant to what it means to have a valid domain. If I have Apache on my server that already hosts other web applications does any domain name I set up with Apache count or do I need to purchase a domain name?
  3. In the previous question I mentioned other applications are going to be on this server. These do not require SSL. If I set up Let's Encrypt and Certbot on my server does that mean that these applications have SSL available or is it specific to the domain(site) name used to set it up? Will any of these other applications need modification if a separate application is using SSL?
  4. Hypothetically lets say I want to get a root certificate but instead of using this with Certbot I want to create and use a set of intermediate keys. Is this possible? Would these intermediate keys need to by altered each time we create a new root key?

I apologize if any of my questions are ignorant, my knowledge of this kind of stuff is very limited. That said, there may even be better options to accomplish what I need so I am open to suggestions. I opted for Let's Encrypt over a self signed cert because with this solution I would not need to add a CA to each client machine that needs access.

Glorfindel
  • 1,213
  • 4
  • 15
  • 22
Newb 4 You BB
  • 169
  • 1
  • 6
  • For what purposes you want to use keys in 4? – Crypt32 Apr 17 '20 at 21:28
  • @Crypt32 if a key is compromised its much easier to replace an intermediate key. Or so Ive heard – Newb 4 You BB Apr 17 '20 at 21:53
  • I don't fully understand your use case. If TLS cert is compromised, you will have to get a new one from LE. – Crypt32 Apr 17 '20 at 22:04
  • @Crypt32 lets say I use a root set of keys to create intermediate keys to distribute to different unconnected and unrelated servers. If one servers keys are compromised I can very easily create a new set of keys from my root as opposed to creating new root keys. Maybe counter intuitive? This was a suggestion made to me – Newb 4 You BB Apr 17 '20 at 22:12
  • 2
    You cannot use LE certificates to create/sign other certificates. – Crypt32 Apr 17 '20 at 22:14
  • Depending on the client machines, you can push a custom Root CA cert through a GPO or custom RPM package – DeadChex Apr 19 '20 at 03:21

2 Answers2

12

  1. Let's Encrypt requires Internet connectivity, but that is needed by the EFF ISRG who run it. Certbot (which runs on your computer) communicates with Let's Encrypt to issue and renew certs and does require connectivity from your computer.

  2. A valid domain name (in the case of Let's Encrypt) is a domain you set up which can be resolved by the global DNS infrastructure - in practice this means using a bought domain name, or a subdomain related to a bought domain name (although it is possible to get free domains from some obscure registries like www.tk)

  3. Applications need to be configured to use the Let's Encrypt keys. All that Certbot does is (a) have a set of keys which almost all browsers accept and (b) signs keys to after checking that the owner of the key is also in control of the DNS for the key that signed. While Certbot can be used with Apache/NGINX, and doing so is easy it does not require either software to run. Similarly the output of Certbot (in addition to optional configuration files if desired, but is in no way mandatory), is a signed public key. This private key, along with the private key (and any intermediate keys) Let's Encrypt typically generates for you can be used by any software you use that can use SSL, recognises Let's Encrypt as a CA and recognises the file format. This needs to be configured in the software.

  4. What you are asking is non-sensical - if you have a root certificate you don't use Certbot. You can create your own CA infrastructure using the OpenSSL library, and if you want to make this easier there are pki tools like easy-rsa. Certbot is not a registry, its not an SSL library, it is a script to verify ownership of a domain name in a standard compliant way, and managing the certs provided by Let's Encrypt. Its not useful if you are setting up your own CA (Certificate Authority - which is what a Root Certificate is all about).

Glorfindel
  • 1,213
  • 4
  • 15
  • 22
davidgo
  • 6,222
  • 3
  • 23
  • 41
  • 2
    The #1 could be more clear: not only Internet connectivity is required, but it also needs to be publicly available for the [HTTP-01 challenge](https://letsencrypt.org/docs/challenge-types/#http-01-challenge). Also, Let's Encrypt is provided by [ISRG](https://www.abetterinternet.org/), not EFF. – Esa Jokinen Apr 18 '20 at 03:52
  • 1
    @EsaJokinen Let's Encrypt and certbot also support the DNS-01 challenge type, which only requires adding a TXT record to your DNS. It doesn't not require that anything other than the machine running certbot have Internet access. The downloaded certificate can then be copied to any system of your choosing. – nstenz Apr 18 '20 at 04:50
  • 1
    @nstenz: i know, and it's also explained in my reference. Frankly, automating the DNS update required for automatic renewals is a bit too hard for someone asking these questions. – Esa Jokinen Apr 18 '20 at 05:04
  • @EsaJokinen - TIL about ISRG. I thought the whole lot was run by EFF, but it appears that CERTBOT is written by EFF while Letsencrypt is run by ISRG. – davidgo Apr 18 '20 at 05:36
2
  1. Yes, to perform any of the challenges involved in creating new certificates, and that's it.
  2. A 'valid domain' is just means 'not an IP address'. Let's Encrypt, like most issuers, will not use IP addresses as the subject of the certificate; it must be a domain.
  3. All Certbot does is create certificates for whatever domain names it sees in your apache / nginx config. You can use the apache / nginx config to enable SSL or not, or point to any other certificate. Certbot will not force your server to have SSL enabled or force it to use its own certificates. Though it can (optionally) write the config for you during the installer.
  4. You can make any certificate act as an intermediate if you have the private key and the optional passphrase.
Jonathan Rosa
  • 189
  • 1
  • 7
  • Thank you for the response. Would the intermediate keys need to be updated as regularly as the root keys? – Newb 4 You BB Apr 17 '20 at 20:29
  • Your answer 1 is correct. Answer 2 is partially correct. Your answer 3 and 4 are wrong. I'll write an answer – davidgo Apr 18 '20 at 00:19
  • @davidgo I couldn't make sense of what he asked for number four. As for number three, are you sure? Applications need to be configured to use the keys, yes, but Certbot can make the config for you, see step three at (https://certbot.eff.org/lets-encrypt/debianstretch-nginx) – Jonathan Rosa Apr 18 '20 at 03:57
  • 1
    @Jonathan.Rosa Yes, I'm sure - while Certbot can read apache configs it does not need it. (There is a mode --standalone which uses its built in server and plugins for other systems, including doing DNS challenges). When I run it for my systems I run "certbot certonly --webroot -w /path/to/website/root -d domain.name www.domain.name" and this does the ACME challenge by adding files to the appropriate place on disk - No apache config reading required. When I renew certs iit relies on structures it creates in /etc/letsencrypt to work out what to renew. – davidgo Apr 18 '20 at 05:27
  • No you cannot "make any certificate act as an intermediate". A server cert (from LE or any other CA) has BasicConstraints{CA:FALSE} and while openssl can be told to use that cert as a 'CA' cert (along with the privatekey as you say) and will actually create a 'child' cert, NO software -- not even OpenSSL itself -- will accept that cert as valid. – dave_thompson_085 Jan 21 '23 at 02:49