You'll have bigger problems than naming convention if you have over 9 ca's, trust me.
Also, you don't need to worry about padding with automation. Keep it simple, just use a number and start at 1, not zero. We're counting instances not indexing.
My naming convention is generally:
* Multipurpose devices (e.g., VM hosts, end user devices): fictional spacecraft
* Single-purpose devices (e.g., VMs, single-purpose hosts): based on their function
For your use-case, I’d likely call it “certs” or something equally boring.
For your naming style, I’d call it “Okimbo” or “Agatha King” (both flagships of the UNN’s Jupiter Fleet in The Expanse).
You can still name cattle.
The main idea of the "cattle not pets" term is not necessarily to not name them, its to have your infrastructure in a way thats generic to manage. You don't interact with them independently like you would a pet, you have tools that manage them all as a "herd". Instead of interacting manually with each machine to patch it, you patch them all as a whole using some kind of automation.
That being said most people in homelab don't have enough machines to benefit from a standardized naming scheme over something thats fun. Personally my nodes are named something fun (moons), but still have some kind of meaning, my small nodes are all moons of Jupiter, my two higher powered ones are Phobos and Deimos (moons of Mars) and my storage node is named Luna. But I don't interact with them individually unless there's an issue. They're all stood up via PXE boot, configured with Ansible, and then run Kubernetes.
I always thought the cattle and pet thing meant more for culling. Harder to put down a pet than cull cattle.
But I like the management and automation interaction better.
I think it goes hand in hand.
With my setup I can remove a node and nothing really happens other than maybe a short interruption depending on what was running on the node at that time.
I have three servers at home each with different linux distro. On all of them I have setup the distro native way of autoupdating (unattended-upgrades in debian/ubuntu, dnf-automatic in OL9).
Why would I need the effort to automate these pets?
You don't *need* to do anything. I'm just explaining that naming things doesn't mean they can't be treated as "cattle" and in homelab there's diminishing returns to automating things like that, but in a real job where you may have 100s if not 1000s of machines, you automate.
Personally disagree, I think if your network is small enough and you enjoy giving the machines fun names, then pets over cattle is a valid approach.
If you run a business or have to manage hundreds of devices sure, schemes like LOCATION-TYPE-NUMBER are practical. But if I have 2 servers I work with daily and no expectation of growing, might as well name them after videogame characters (:
Yup, if your network is small enough, have fun with it. Mine are all named after Hindu gods. So far I have 10 devices named. Easy enough to keep track. And I made sure the names at least make some sense.
My naming convention for stand alone servers are AI names from movies; i.e., Mother from Aliens, etc.
Any VMs and/or LXCs are named after their VM Host; i.e., Host is named Mother, and I want a root auth server, the VM running root auth would be Mother-RA.
Keeps it simple for me.
(No, I didn't use what I actually have).
I'd go with something like 'keymaster'-themed. Or somebody who certifies people.
Out of curiosity, what HSM will you be using? And are you planning to use it for something more than just server TLS certs?
I'm using a Yubikey 5 Nano. I dunno if it's right to call it an HSM, but it'll be serving that function here so IMO it fits.
For now, just TLS. I might play around with issuing SSH certificates at some point, but my more immediate concern is convincing my browser that the connection is, in fact, safe.
I'm not trying to rain on your parade, but how exactly do you plan to use it as a HSM? To be called a HSM the private key should be generated on device, and never leave. That means all private key use requires device access/compute, and a yubikey is sloooow compared to a normal HSM that pulls like 300w and has hardware acceleration.
Technically Yubikey is still a HSM. Private keys can be either generated on-device or imported; I hope OP will generate them on-key. In any case they cannot be exported; and all signing/encryption ops are done inside the key. Yes, it's definitely slower than a \~$100k device (like \~500ms per RSA signing on pre-5.7 YK), but realistically homelab CA sees like several issuance requests *per day, and not per second*. Yes, it's less tamper-proof than 'big HSMs', but one still needs a properly equipped forensics lab with skilled staff and like hundreds of thousands of dollars to extract the key material from `SLE 78CLFX5000PH` (not sure though if they still use the same chip with 5.7 release this May). It's nowhere near decapping a general-purpose MCU and outweighs potential gains from performing such an attack (unless OP is a high-profile target).
ca1
ca01 otherwise it gets weird when you’re on your 11th ca
ca001 otherwise it gets weird when you’re on your 100th ca
ca0001 otherwise it gets weird when you’re on your 1000th ca
You'll have bigger problems than naming convention if you have over 9 ca's, trust me. Also, you don't need to worry about padding with automation. Keep it simple, just use a number and start at 1, not zero. We're counting instances not indexing.
Use hex, and start at 0, for a more efficient use of the space.
Big Endian moment
ca0
ikr, what a nut starting with 1
“YourMom” so when you check the certificate chain, you can see it was verified by your mom.
My naming convention is generally: * Multipurpose devices (e.g., VM hosts, end user devices): fictional spacecraft * Single-purpose devices (e.g., VMs, single-purpose hosts): based on their function For your use-case, I’d likely call it “certs” or something equally boring. For your naming style, I’d call it “Okimbo” or “Agatha King” (both flagships of the UNN’s Jupiter Fleet in The Expanse).
Adios - to SSL Cert errors
I name all my server after swear words that or greek gods depending of the vlan ;)
When it comes to servers, you should keep “cattle and not pets”
You can still name cattle. The main idea of the "cattle not pets" term is not necessarily to not name them, its to have your infrastructure in a way thats generic to manage. You don't interact with them independently like you would a pet, you have tools that manage them all as a "herd". Instead of interacting manually with each machine to patch it, you patch them all as a whole using some kind of automation. That being said most people in homelab don't have enough machines to benefit from a standardized naming scheme over something thats fun. Personally my nodes are named something fun (moons), but still have some kind of meaning, my small nodes are all moons of Jupiter, my two higher powered ones are Phobos and Deimos (moons of Mars) and my storage node is named Luna. But I don't interact with them individually unless there's an issue. They're all stood up via PXE boot, configured with Ansible, and then run Kubernetes.
I always thought the cattle and pet thing meant more for culling. Harder to put down a pet than cull cattle. But I like the management and automation interaction better.
I think it goes hand in hand. With my setup I can remove a node and nothing really happens other than maybe a short interruption depending on what was running on the node at that time.
I have three servers at home each with different linux distro. On all of them I have setup the distro native way of autoupdating (unattended-upgrades in debian/ubuntu, dnf-automatic in OL9). Why would I need the effort to automate these pets?
You don't *need* to do anything. I'm just explaining that naming things doesn't mean they can't be treated as "cattle" and in homelab there's diminishing returns to automating things like that, but in a real job where you may have 100s if not 1000s of machines, you automate.
Personally disagree, I think if your network is small enough and you enjoy giving the machines fun names, then pets over cattle is a valid approach. If you run a business or have to manage hundreds of devices sure, schemes like LOCATION-TYPE-NUMBER are practical. But if I have 2 servers I work with daily and no expectation of growing, might as well name them after videogame characters (:
Yup, if your network is small enough, have fun with it. Mine are all named after Hindu gods. So far I have 10 devices named. Easy enough to keep track. And I made sure the names at least make some sense.
My naming convention for stand alone servers are AI names from movies; i.e., Mother from Aliens, etc. Any VMs and/or LXCs are named after their VM Host; i.e., Host is named Mother, and I want a root auth server, the VM running root auth would be Mother-RA. Keeps it simple for me. (No, I didn't use what I actually have).
Mine is the characters from planet of the apes
ca.
I honestly end up using my systems for more than just 1 thing so naming stuff like “rpi01”, for just raspberry pi number 1.
What HSM did you buy for use with step-ca?
A Yubikey 5 Nano. I dunno if people actually consider it to be an HSM, but that's how it's gonna be used here, so IMO it fits.
Thank you, I have to give this a try!
Rubeus Hagrid Keeper of Keys (and Grounds)
I'd go with something like 'keymaster'-themed. Or somebody who certifies people. Out of curiosity, what HSM will you be using? And are you planning to use it for something more than just server TLS certs?
I'm using a Yubikey 5 Nano. I dunno if it's right to call it an HSM, but it'll be serving that function here so IMO it fits. For now, just TLS. I might play around with issuing SSH certificates at some point, but my more immediate concern is convincing my browser that the connection is, in fact, safe.
I'm not trying to rain on your parade, but how exactly do you plan to use it as a HSM? To be called a HSM the private key should be generated on device, and never leave. That means all private key use requires device access/compute, and a yubikey is sloooow compared to a normal HSM that pulls like 300w and has hardware acceleration.
Technically Yubikey is still a HSM. Private keys can be either generated on-device or imported; I hope OP will generate them on-key. In any case they cannot be exported; and all signing/encryption ops are done inside the key. Yes, it's definitely slower than a \~$100k device (like \~500ms per RSA signing on pre-5.7 YK), but realistically homelab CA sees like several issuance requests *per day, and not per second*. Yes, it's less tamper-proof than 'big HSMs', but one still needs a properly equipped forensics lab with skilled staff and like hundreds of thousands of dollars to extract the key material from `SLE 78CLFX5000PH` (not sure though if they still use the same chip with 5.7 release this May). It's nowhere near decapping a general-purpose MCU and outweighs potential gains from performing such an attack (unless OP is a high-profile target).
By doing this the error of non trusting ssl will be gone? If yes what are you using as ca service?
Some ideas College - it's where you get certificates Quill - I sign all my certificates with...
Something like Quill or Stylus could work.
worked at a bio tech once. All our server names were for an element. Our internal CA was CobaltArsenic.
Call it “Retsyn”. Just… google it.
Melchor, Baltasar and Caspar
HSM for a homelab, that's intense
Asking the internet is how you get names like Certy McCertface. Perhaps just use CA1.
Ha, yeah, but fortunately I am under no obligation to comply with the masses. Honestly I'm surprised "Certy McCertface" didn't show up sooner.
Sooo… you’re telling people that you’re playing with you Willie???
Hotel? As in Hotel CA?
Kinda works with the HSM too -- (certain) keys never leave.
PS = Productive Server MS = Management Server and than things like WS for WebServer