Question about subdomain certificates

Issuance Tech
1

Greetings,

I have been directed by my organization to investigate the possibility of moving to Let's Encrypt for our public-facing web services.

This organization has many public facing web servers under the same domain. I have been directed to investigate whether we can obtain a certificate from Let's Encrypt for our domain root, and then issue certificates to our subdomains using our own COTS key-vault solution.

Based on what i am reading in the documentation portal, i believe the answer to this question is "no".

If my understanding is correct, what is the appropriate/recommended solution for this? Must we install an ACME client on every web server and configure them to retrieve their own keys directly from Let's Encrypt? Is there any way for us to integrate a COTS key vault so that we can manage the issuance of certificates centrally and internally? We have dozens of subdomain sites which require certificates, and it would be quite cumbersome to get all of the web admins within our enterprise to configure and maintain the ACME client on each of their servers.

Just looking for some guidance on what the options are. Thanks!

2

You can centrally procure all the certificates using a single machine and ACME client using the DNS-01 challenge. I recommend using CNAME delegation from the main DNS system onto a secondary DNS system to safeguard the credentials to the primary DNS system. I like acme-dns, but any commercial vendor or self-hosted solution will work.

You can then deploy those certificates to your key-vault system and have the servers pick them up.

1 Like
3

I think you may just be confusing things by asking about if you can "issue certificates" yourself. All issuance for publicly-trusted sites comes from the publicly trusted CA. But you can certainly have one system responsible for validating names and asking the CA to issue the certificates, and then centrally distribute the certificates from there to the systems that need to use them. (Though having each system responsible for automating its own certificates can work fine too.)

Maybe you can describe more about how you're currently automating getting, distributing, and installing certificates from whatever CA you're currently using? And why are you looking at moving to Let's Encrypt? Many CAs have free domain-validation certificates, and many CAs support ACME for automation. Let's Encrypt does both, sure, and is a great place to get your certificates from, but there are other good choices available too.

2 Likes
4

You cannot use a Let's Encrypt end-entity certificate to issue new certificates.

1 Like
5

we currently have no automation. we have a single person responsible for submitting certificate requests for long-term certs to DigiCert and issuing those certs to the requesting admins.

We have been directed to look into Let's Encrypt as the organization leadership is no longer interested in paying for certificates, and the person currently managing our DigiCert inventory recalls that the org used to use Let's Encrypt 5-10 years ago.

A solution like jvansco suggest above would be acceptable. I just need some direction on reading materials for how to set it up and what it would look like from a process flow and technical requirements standpoint. I have never personally had cause to manage web certificates before, but this has landed in my lap because the org has recently downsized its workforce and lost staff who would have been more appropriate to the task.

1 Like
6

can you point me to some recommended reading on how this setup would look?
This sounds like it will fit our need, but i have never personally managed web certs before. This has fallen in my lap due to staffing cuts. I'm more of a network/firewalls guy, so anything you can point me to for understanding how to make this work would be great.

what i think you are proposing is:

  1. set up a server to run the acme client and submit requests to Let's Encrypt for every subdomain that needs a cert (s1.example.org, s2.example.org, etc etc)
  2. set up a script or client to publish the certs to our internal key vault for distribution.

Item 2 i believe i have the materials i need to get working, but item 1 is where i have knowledge gaps.

7

Even with dozens of sites, especially if each site has its own "web admin" handling its own system I think tackling it one site at a time may be the easiest approach, by having each one installing an ACME client (like certbot) and configuring their own system. Once the initial effort is in to have it installed and working, then it's automated from then on and just requires monitoring.

If you really want the centralized system, I think there are off-the-shelf tools for automating everything, but others here can probably give better recommendations than I could.

Depending on your architecture for running your various sites, if you want to handle it from the network/firewall approach to just "put something in front of it", you may want to look at software like Caddy to run your sites in front of your existing systems, have the existing systems stop handling certificate installation at all, and just let Caddy handle acquiring certificates as needed.

I think for more specific recommendations you'd need to say more about what kinds of systems/software you're using for running your web servers.

2 Likes
8

Oracle, RHEL, Windows Server, AWS-hosted sites. you name it, we probably have it.

allowing systems to directly retrieve their own certs is going to be unpalatable to org leadership (though i'm still keeping it in the list as 'possible') as we already have serious issues with shadow IT inside the enterprise. Forcing web admins to go through our central IT office is one of the control methods we are using to keep a lid on rogue developers.

2 Likes
9

I'll just add that instead of using acme-dns some DNS providers like Azure and AWS Route 53 support fine-grained security for updating records. These are also well supported by ACME Clients to handle a DNS Challenge for getting a cert. If one of those is already your provider, it would likely be simpler to use them directly rather than the extra complexity of acme-dns.

4 Likes
10
  1. set up a server to run the acme client and submit requests to Let's Encrypt for every subdomain that needs a cert (s1.example.org, s2.example.org, etc etc)

This does not need to be on a server. This can just be your work machine, or another work machine. I do this from my laptop all the time.

The DNS-01 authorization works by inserting a TXT record onto:

  • _acme-challenge.example.com for example.com
  • _acme-challenge.subdomain.example.com for subdomain.example.com
  • _acme-challenge.subdomain-alt.subdomain.example.com for subdomain-alt.subdomain.example.com
  • etc.

LetsEncrypt will follow CNAME records, so you can either:

  • Manipulate the primary DNS records, or
  • CNAME the _acme-challenge record onto another system.

I prefer to use both CNAMEs and acme-dns. You can use CNAMEs with any DNS provider. The benefit of using CNAMEs onto a secondary DNS provider, is that you can be less worried about the credentials being compromised. This is the best-practice and essentially required if you run the Acme Client from an internet connected server - you don't want to risk a server compromise leading to control of all DNS records or potentially domain registration.

This concern is largely explained in this blog posting: A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation | Electronic Frontier Foundation

An alternate option is if you have a primary DNS system that offers granular control of token credentials. I.e. you can configure a token to only alter CNAME TXT records, or select TXT records. I believe Azure and Route53 both support this.

The general flow of the DNS-01 challenge, using Certbot as an example:

Variation A - Direct DNS Control: a dns-01 plugin will manipulate the DNS records, you shouldn't have to do anything differently for onboarding or renewal.

Variation B - Secondary DNS CNAME: this varies by plugin/dns provider, but in general: the client will pause during onboarding and ask for the CNAME's target, you set that up manually, and the client will then manipulate the target record instead of the source record. renewals should not pause, and just use the stored credentials for the target record.

The big work effort here is either in:

  • ensuring you have locked-down credentials that can only alter the relevant _acme-challenge TXT records (if you have a DNS provider with granular control), or
  • setting up the secondary DNS system, whether it is a vendor or self-hosted

The onboarding of every domain will either be generating a new credential or expanding the existing token to handle the new acme-challenge DNS entry, or creating the CNAME record from the primary to secondary system.

set up a script or client to publish the certs to our internal key vault for distribution.

If you use Certbot, there is a "post-deploy" hook to leverage for this. I like to script these things with Fabfile.org

I hope that makes sense.

6 Likes
11

You will need to create a CAA record with an account uri. A general CAA record is used to restrict issuance to a specific CA (such as LetsEncrypt); you need to create one with an account-uri to restrict issuance to only a specific ACME Account -- otherwise your rogue staff can get certificates via HTTP-01 challenges.

4 Likes
12

thanks, this looks like what i need. I will research these topics further. I appreciate everyone taking the time to help me learn!

4 Likes
13

Well, that could happen today. They wouldn't need to restrict CAA to a specific account. Just restricting to DNS challenge should be enough. Assuming access to the DNS is suitably restricted. See: Certificate Authority Authorization (CAA) - Let's Encrypt

4 Likes
14

you may want GitHub - dvtirol/serles-acme: Pluggable ACME: a tiny ACME-CA implementation to enhance existing CA infrastructure
only proxy holds DNS api key, internals makes challenge to proxy and proxy ask real CA for certificate then sent it back to internal clinet

3 Likes