Join Log in
Score:1
avatar Server

How to solve chicken or the egg issue with client TLS certificates on a physical host?

pe flag
Arseni Mourzenko

I don't understand how to solve chicken or the egg problem when automating the installation of the servers.

I have a series of servers which can be rebuilt through PXE. When a machine is being rebuilt, it loads all the settings it needs—including its private certificate it will use to authenticate itself when using different services later on—from an Apache server. This Apache server identifies the clients by their IP addresses in order to either serve them the configuration or the certificate intended for a given server, or refuse to serve it.

However, the IP address of a client could be spoofed. Same for MAC address, if at some point I add this sort of verification too.

In order to grab its configuration and its private certificate safely, the machine which boots through PXE should therefore already have a certificate that it could use when communicating with Apache server. This, however, doesn't look possible, as a machine which boots from PXE is either fresh new, or will format its disk anyway during the installation.

Am I missing something? How can I identify a fresh new machine without the risk of spoofing?

Should I use an always connected USB key which contains the private key? Or are there other options?

115
0 + 0
in flag
NiKiZe
Private parts of a certificate should never go over the wire in the first place. TPM can be used to reliably recreate a private key, which then generates the public key, which then can be used to create a certificate.
0
Reply
pe flag
Arseni Mourzenko
@NiKiZe: I'm not sure how it works. Imagine I have a fresh machine, no operating system installed. How do I put a certificate in TPM in the first place? What do you mean by the fact that TPM can recreate a private key? How does it know anything about CA?
0
Reply
in flag
NiKiZe
You don't put much into it in the first place, you activate it and it gives you a random permanent blob - as long as nothing in the boot process changes, if it does, then the key changes as well.
0
Reply
Score:2
avatar Server
cn flag
natxo asenjo

We use the foreman's bootdisk plugin for this purpose. I do not imply it's the correct or unique way, it's what we use successfully.

Everytime a host needs to be (re)provisioned, a short lived token gets generated and it's kept on the database coupled to the host. This token goes into an iso file with the ipxe binary and a script that downloads the kicstart file from the provisioning host only if it offers the right token as identifier. Once the host is provisioned, the token gets deleted. After a specific (tunable, out of the top of my head defaults to 60 minutes) the token is invalidated.

This works with both bios as uefi firmware, and no need for pxe, just http(s) so you could really have internet deployments with few modifications (handy for deploying hardware on remote locations).

0 + 0
pe flag
Arseni Mourzenko
If a hacker gets his hands on the token *just before* the server which is being provisioned does, then the hacker would get access to the resources, but while he does, the provisioning will fail, and the system administrators will be alerted that something nasty may be going on. Makes sense, indeed.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

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.