Score:0

Creating a dynamic SSL cert infrastructure for VMs/containers in sub-domains, some of which are intermittently air gapped

aq flag

I am requesting help to create an infrastructure for dynamic SSL certs for use in containerized environment on multiple sub-domains of myrootdomain.com, some of which may have intermittent internet access. Let me explain.

  1. We registered myrootdomain.com (not the real name, obviously) as a root domain.
  2. We will have multiple sub-domains, e.g., sub1.myrootdomain.com, sub2.myrootdomain.com, etc.
  3. Most of those sub-domains will be on-prem in various countries around the world.
  4. We need the ability for these on-prem solutions to create dynamic SSL certs for VMs and containerized services, even when the on-prem network is disconnected from the internet.
  5. These on-prem networks will be immutable Infrastructure as Code and these dynamic SSL certs will have short TTLs, as the containers are never intended to live long.
  6. This would need to function in an air gapped environment.

We initially thought that we could purchase an SSL cert for the myrootdomain.com domain, then from that "parent" SSL cert on myrootdomain.com generate an intermediate cert for each sub-domain, from which we could generate dynamic SSL certs for the containers and VMs. As containers and VMs are destroyed, so are their certs. As containers or VM are spawned, a new SSL cert based on the intermediate cert of the sub-domain, would be generated and assigned. This would need to function in an air gapped environment.

What type of cert is needed on the myrootdomain.com domain? What type of certs are needed on the sub-domains? Where can I find some references for this use-case? Thank you for your time.

We reached out to 101domain.com (where the domain is registered) SSL support who told me we would have to regenerate the SSL cert on the root domain every time. I know that is incorrect, so we escalated the ticket to the engineers. I'm waiting on their response. In the meantime, I thought I'd ask the community.

I've Googled all manner of dynamic SSL certs on containers and VMs, but I haven't found anything relating to building the infrastructure for it or the type of certs needed. I'm sure it's because I am not using the right buzz words in my searches. You don't know what you don't know.

Lukman avatar
cn flag
Is wildcard SSL not an option for you?
Shawn avatar
aq flag
No, unfortunately the wildcard SSL is not an option for us.
Score:0
in flag

You would need a subordinate CA certificate if you wish for the certificates to be recognized by clients without specific configuration on the clients.

As you want this subordinate certificate to be able to issue certificates only for names under a specific domain, a Technically Constrained Subordinate CA Certificate, as defined by the Baseline Requirements would be enough for you.

I couldn't find a CA selling them through a quick search, but you might need to contact them. It will most certainly come with constraints on how you can store the key for this certificate and what kind of certificate you can issue through it, which will be regularly audited by the CA.

If this is only meant for clients you control, setting up your own pki and adding it to your clients might be easier.

Shawn avatar
aq flag
I know we can build our own PKI infra for clients, but the trust chain is almost worthless as there's no root trust (an actual CA). This is my first time building a containerized IaC network. Is the self-signed PKI infra normal in this use-case? Thank you for your time and advice. It is much appreciated.
in flag
I haven't built a containerised IaC network, so can't say if setting up a self signed PKI is normal. Setting up a PKI implies setting up an actual CA: yours. If you control the clients, you just add trust in your CA, or even replace trust in the myriad of default CAs by trust in your own. Kubernetes for example uses its own PKIs to authenticate the various nodes, not a public one. It then becomes a problem of whether you trust yourself to keep your CA safe (you can technically constrain it to reduce the risks, though some applications might not support constrained (sub-)CAs).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.