I'd keep in mind that one specific Yubikey will become a Single Point of Failure. I could talk for a long time how consuming can customers' client certificate replacement be, plus redoing whole PKI from scratch.
I love this channel. I've had a handful of tabs open on smallstep for MONTHS. Now I don't have to do any pesky reading. Thank you for helping me learn good easy Apalrd!
I was using my own CA, painfully copying my root certificate to be trusted in all my devices, before let's encrypt was a thing. The main issue for me was that Android keeps a permanent warning message when manually adding a trusted root certificate. Basically, all the ecosystem is designed to trust all keys with the major CAs and doesn't allow you to trust your own. For "safety". Unless you root your phone, of course, which I can't do on my device. Let's encrypt fixed that for me.
Thank You for Making this video. I followed your proxmox LXC with hardware acceleration for Jellyfin as well (using this daily). Your content has been very useful overall and I appreciate it.
I just started working on a bachelors in IT I am overwhelmed with the information and allowing myself to think way to hard about things. You really are so much better at helping me understand. I really hope to learn more from you. I wish you could be my tutor. Thanks for the videos…
Yay for smallstep-ca! I have a similar setup at home, using a SBC, a source of randomness & a yubikey. The only thing not working ideally is using the step-cli to renew certificates, if the certificate it's trying to renew is expired it won't to attempt to anything. Using Caddy like in the video works even if the certificate has expired.
@@apalrdsadventures I'm using step-cli for systems where I don't want to configure and run caddy, so I can run prometheus exporters with a valid certificate (and mTLS at some point). I wrote an ansible playbook to bootstrap all of this but it's a bit hacky. Looking forward to see your experiments in this as well!
I did try other ACME clients with it as well (such as Proxmox's native ACME support), but Caddy was the easiest example. I currently have mTLS running with a cert on my laptop and workstation, but I'm still not happy with the deployment and renewal process yet for end users. It's great when it works though! No more logins (if the backend software supports it)
SSH keys are a bit of a different beast (since they aren't x.509 based), but they are still using the same underlying crypto (RSA + AES or ChaCha20) and still support certificate authorities and chains of trust. It's on my todo list, but the implementation is quite a bit different than TLS certificates.
Excellent video! Makes me thing... Maybe make a bootable USB (encrypted; maybe readonly) for the Dell WISE thin client. Easy migration etc. Have some config to write logs (syslog) to a common server, or use Kafka to keep a ledger and records of CRL and CT data.
There are a ton of options for how to better secure the CA, but in general key rotation is the most effective. This is why it issues 24 hour certs over ACME, to minimize the fallout if a private key is compromised. -On a system with TPM2 you can secure boot your way to a validated kernel and initrd (either distro signed, or a specific image if you want, which means software updates will cause secure boot to fail), and from there you can mount the root partition (potentially encrypted via TPM also) to store the CA database (by default in Smallstep it's a BadgerDB key-value store). None of this protects your CA directly since the system is still decrypted while running (other than the Yubikey), but rebooting regularly at least means the kernel and initrd get re-validated. -If you keep an entirely airgapped machine with the root private key, you could re-issue Yubikeys regularly and physically change them out on the intermediate CAs. If you do this monthly, at worst the attacker can issue new certs valid for roughly a month. This would involve physically swapping out the yubikey monthly if you want to keep the root machine airgapped, or only booting it up every month to remotely sign the new intermediate keys. -Client certs (especially hardware-bound client certs) would really prefer a longer lifecycle than server certs since clients can be off-network for some period of time, so this is a consideration when you think of rekeying intervals, especially if clients need a still-valid client cert to renew.
I'm not aware of any web browsers that support DANE in 2024, so it's kinda irrelevant now. If you use a Mobile Device Management (MDM) system such as Intune it can provision the root cert to devices for you. Otherwise you have to do it manually.
@@apalrdsadventures Thanks. Was looking for an alternative to just Intune (Am not a fan of Microsofts stuff). And who has money for an E5 or F5 license for a home lab?
In the end, you still have to go through every client device and import a custom root ca though, right? If not, I probably misunderstood something and that's fine. I learn more from uncovering misunderstandings. Copying a self-signed root ca is what I used to do too but device management became a nuisance and I ended up going the reverse proxy / let's encrypt route to make things work.
I just got around to implementing this myself, and I'm wondering why you didn't generate the intermediate key directly on the yubikey? Instead opting to generate it on the computer and importing it?
Just to nitpick a bit, aren't ed25519 sorta of prefered nowdays? And can't you just create the certificate straight onto modern yubikeys so they never have to get temp saved on a machine? :)
ed25519 is easier computationally than RSA, but the security level is roughly the same. It's widely preferred because it reduces the workload on web servers who need to sign TLS connections all the time. For root certs, we are signing things basically never, so compatibility is more important. For intermediates, we could go either way. In very niche applications, ed25519 was never accepted (i.e. NIST FIPS requirements for government work), so generally RSA is seen as more compatible. In theory there is also stuff that only supports RSA, but in reality that stuff probably doesn't support TLS >= 1.2 so you don't want to be using it anyway. As to generating the intermediate on the yubikey, yes, you can do that. You should still use an offline root though, with a shorter life on the yubikey, so you can replace the yubikey and sign a new intermediate in the future.
Can the OpenSSL step be skipped in favor of writing the root & intermediate keys generated by the step-ca init to the Yubikey? I suspect that you started with OpenSSL to introduce the concepts using a tool familiar to your audience which is quite wise, but just wondering…
I see that you need to tell caddy (a webserver?) to use step-ca as you CA. I assume that you also would need to tell proxmox and all other web services/webservers to have their certs signed by step-ca (e.g., promox cluster ca would need to be configured to have its cert signed by step-ca) is that correct? Does each webservice / webserver need to be manually configured or is there a way for each machine / VM / container to be configured so that all the certs it sends out via ACME get automatically signed by step-ca?
Most ACME clients default to either Let's Encrypt or require you add the ACME server. So you'll need to set your ACME directory in the config of the ACME client.
Can we adapt your guide to utilize the step-ca docker image option for yubikey ? I have a plan to migrate my CA & other auth services to a single system in near future, but want to setup the CA server early.
Thank you so much for this, I have one request if you can, please can you make tutorial on virtual networking inside proxmox. I have a laptop which i want to use it as my web server. It has one LAN port. I want to use that LAN port to connect to internet, then i want to have a vm (pfsense) for my networking needs (like dns and firewall), then finally i want my other vm's (like website, storage server, jellyfin etc) to connect to the pfsense server and to internet eventually so that all of it can be accessible over internet anywhere. Can you please make a video on it like a casestudy or can you point to a guide or anything. Please Please please.
@@apalrdsadventures i saw that and that really helped me understanding those concepts. I was only using vlans prior to that. But what i am not able to understand is how to fit those concepts for my use case. Can you help me?
With only one Yubikey in my setup, the goal is to keep the root totally offline (it has an extremely long validity) and periodically bring it out of offline storage to re-sign the Yubikey. This works well at this scale. Of course, the root could still be a Yubikey itself that I just plug in every time I need to re-key. The Yubikey itself is adequate to store a small number of certs/keys in hw and do some operations on them. The YubiHSM can store a lot more keys in hw, provide multiple access with different permissions to each key, supports Microsoft AD CA directly, and has built-in audit logging. So it depends on your needs.
So theoretically, having four yubikeys, one could create their root on one, sign three intermediates (or more if needed of course), and then use as needed? I believe the only caveat I found with using a YubiKey as the root storage is the size limitations. It won't go to 4096 RSA. That might be the main blocker for some wanting that route I guess. IIRC, YubiHSM has the same size restrictions, just more slots and control as you mentioned? I honestly may just look to getting some encrypted drives to store the private key, do all the offline isolated magic as you have, and have flexibility to move the key as I see fit. Good example could be flaws found in YubiKeys and replacements offered. Sure, you have the latest firmware, but zero way to truly upgrade to the patched one. Only replace. Thanks!
Have you considered an alternative to Yubikey? An intermediate key added as data to a PNG file. PNG file with any graphic (e.g. cat) and any name (e.g. cat.png) saved to usb flash drive. The file browser treats this PNG file as a typical photo. When debian detects the PID:VID of this usb flash drive it extracts the intermediate key from the PNG file. (udev script) I think you understand what I mean?
The downside to this is you can export the private key from a flash drive, so the extracted key file could be compromised. The Yubikey can't export the private key, only sign in hardware using the key. Smallstep also supports PKCS#11 HSMs including the TPM2 standard, which could be a good option on modern systems. But the Yubikey 5 is the cheapest HSM which Smallstep supports as far as I know.
@@apalrdsadventures If the private key was encrypted with a password generated from a checksum generated from another flash drive serving as the password for that encrypted key, would it still be a bad idea?
Ultimately the key needs to be decrypted to be used, so the information necessary to decrypt it is available to an attacker on the system. Would they figure it out? Maybe, maybe not.
@@apalrdsadventures If, in my example, I lose the second flash drive and do not write down its checksum for myself in a safe place (I would use SHA512) then I will not get to the private key. The attacker would have to figure out that the password is the checksum of the second flash drive.
The attacker would probably start by reading the Smallstep config file and finding where the private key is supposed to be stored, then looking for a key file in that location (presumably decrypted on boot into a RAM disk so Smallstep can use it). Ultimately, Smallstep needs to sign things and by reading the config file you can work backward to find the key / the script that loads the key on-demand.
I would be much more inclined to run my own CA like this if its root certificate had a flag indicating it was only valid for a certain domain. Unless I've missed some new developments in the PKI system this isn't possible. If a bug results in my CA signing a rogue certificate for Google then suddenly I can no longer trust connections to Google.
If anyone managed to compile step-ca for arm64, I'd appreciate to learn how you did that. My attempts at step-ca cgo builds fail with 'no such instruction' errors. Looks like building this on a RPi is out for the moment.
Aww sorry this is so cool but the fact that you need to do something in every client device (in this case trust the root cert) kills the whole idea. In my case I bought a domain name, then proceed to generate a wildcard cert with lets encrypt using a dns challenge and done. But knowing all the process is great! thank you
There are a lot of uses for certs other than TLS server certs - for example I use this setup for TLS *client* certs, but it's also commonly used with VPN or WiFi certs for example.
I dont get the point of this. If someone hacks the server, they may not be able to get the key, but they will still get all the important functions of the key because the yubikey secrets are store plainly on the server. So they you wont be able to trust certs signed by that cert. And unless you have a good way of doing certificate revocation lists, you'll in practice need to untrust the root CA anyway. It could be argued this protects against physical key theft but even then its only if the server's yubikey secrets are encrypted and the server is otherwise locked down (no console). Most home servers don't meet that. So in summary this seems to only inject complexity and unnecessary software into the public key infrastructure.
The root cert is stored offline after it's created, so only the intermediate cert is on the CA system at all. So now we have a shorter lifetime (1yr intermediate vs basically infinite) to begin with, which limits the length of an attack. You can reduce this time down further if you are willing to re-key the yubikey more often. Next, the Yubikey can't export it's private key, so while someone could sign their own certs using the Yubikey, they can't steal the private key itself, so they are limited in how fast they can sign new certs. If they are going through step-ca, it will only issue certs with a ~48hr validity, so that's the limit of what an attacker could get. If they manage to hijack the system entirely, then they could issue certs up to the validity of the intermediate cert on the Yubikey. All of this makes the PKI more secure than keeping the root cert on a server somewhere.
@@apalrdsadventures Thanks for responding. I agree with the benefits you mention but not sure I agree that they are valuable in a homelab. But I can imagine some scenarios that would benefit depending on what threats one is worried about.
21:45 might be a better idea to have the CA HTTPS SSL cert issues by Let's Encrypt or other trusted CA. To make sure what you are downloading is more likely to be correct.
Yeah ! Great to hear you are going to do mutual-TLS ! Great stuff ! Some other tips: set up OCSP and/or CRL as well. Short lived keys is already a good start, but my guess is this won't be practical for the clients...?
The hard thing with CRLs/OCSP is most clients don't actually use them. But for mtls, I can at least force Caddy to query it (I think, I haven't tried). Currently for testing I issued 2 month certs for my test clients, but I'm not a huge fan of that. My *hope* was to use hardware-bound keys on clients to avoid the need for short-lived keys, but testing with Yubikeys it's a bit of a pain (Firefox makes you retype the PIN every few minutes) and Apple doesn't allow their hardware-bound keys to be used aside from with mobile device management apps. So now I need a new plan. For 'on-network' clients a few days cert and automation to renew would probably be fine, but more transient devices might still not be on once a week.
@@apalrdsadventures what I've done for now, I used it only for checking the status of the client-certificates for authenticating to the servers. So when I need to revoke a client-certificate (not often): I add the revoked client to the CRL-file signed by the CA and update the CRL on each server by hand. Not pretty, but at least it doesn't depend on an OCSP server being online, etc.
Yes, but why? A given service can only use certs issued by one authority. Clients can trust any number of authorities. It’s also possible to issue 2 intermediates from the same root if you want multiple locations or redundancy.
You can use the single offline root key to generate multiple intermediates for redundancy (on multiple yubikeys / ...), and then host multiple CAs using an intermediate key for each. All of them are signed by the root, so there's one hierarchy, but you can issue leaf certs from any intermediate.
@@apalrdsadventuresit's possible to have 2 roots, you send the csr to be signed by different authorities, ones that's done the cert is trusted by both due to them having the same public key. This is how let's encrypt recent rolled over to a new root without needing to resign certs
Let's Encrypt signed their intermediate cert with two roots, ACME clients aren't really designed to issue from two CAs at once. You could do the same and sign the intermediate cert from two roots, but if you are looking for redundancy it would make more sense to replicate at the intermediate level (however you choose to do that)
NGL, you can skip the "attention grab" at the start, we know what this channel is and I clicked on the video bc the title had something I want to learn.
when i run sudo -u step step-ca /etc/step/config/ca.json i am getting below error. how to solve it? authority.GetTLSCertificate: error creating certificate: x509: requested SignatureAlgorithm does not match private key type
![Devenez votre propre autorité de certification 🔏 step-ca [Docker, Proxmox, ACME, TLS, X.509, SSH]](http://i.ytimg.com/vi/b220TwUUOzY/mqdefault.jpg)
We need to Ansible this :) Awsome video thank you so much as always
First things first, let’s make sure cert renewals are automated
Thank you for specifically mentioning that a yubikey can be used to store the certificate key and that smallstep can access it! Great video.
I'd keep in mind that one specific Yubikey will become a Single Point of Failure.
I could talk for a long time how consuming can customers' client certificate replacement be, plus redoing whole PKI from scratch.
Thanks for making this great tutorial, apalrd! 🥰
Excellent video! Thank you so much. Cryptography is hard as you mentioned and this is of great help. Looking forward for the next chapters...
I love this channel. I've had a handful of tabs open on smallstep for MONTHS. Now I don't have to do any pesky reading. Thank you for helping me learn good easy Apalrd!
Man you are covering stuff I was planning on looking at and setting up but have not had the time. greate work.
Hey apalrd, you're doing great work with educating people. Keep it up!
As always, excellent delivery, nicely paced. Keep up the good work, it is very much appreciated
I was using my own CA, painfully copying my root certificate to be trusted in all my devices, before let's encrypt was a thing.
The main issue for me was that Android keeps a permanent warning message when manually adding a trusted root certificate. Basically, all the ecosystem is designed to trust all keys with the major CAs and doesn't allow you to trust your own. For "safety".
Unless you root your phone, of course, which I can't do on my device.
Let's encrypt fixed that for me.
"Apple - Are - D" So that's how you say it!
yup that's correct
I was wondering this also
Thanks I'm looking forward to more episodes about this
Thank You for Making this video. I followed your proxmox LXC with hardware acceleration for Jellyfin as well (using this daily). Your content has been very useful overall and I appreciate it.
Glad it helped!
@@apalrdsadventures would this certificate process work well for jellyfin and jellyfin android and/or google tv clients? Thank you!
Cool !!! great Video.. Will be nice get same solutions to manage the ZFS key for pool severs of truenas..
You are amazing dude! Love your content.
Thanks!
I just started working on a bachelors in IT I am overwhelmed with the information and allowing myself to think way to hard about things. You really are so much better at helping me understand. I really hope to learn more from you. I wish you could be my tutor. Thanks for the videos…
Yay for smallstep-ca! I have a similar setup at home, using a SBC, a source of randomness & a yubikey. The only thing not working ideally is using the step-cli to renew certificates, if the certificate it's trying to renew is expired it won't to attempt to anything. Using Caddy like in the video works even if the certificate has expired.
I haven't used step-cli for server certificates, just client ones, and I'm still working on a good process for dealing with those.
@@apalrdsadventures I'm using step-cli for systems where I don't want to configure and run caddy, so I can run prometheus exporters with a valid certificate (and mTLS at some point). I wrote an ansible playbook to bootstrap all of this but it's a bit hacky. Looking forward to see your experiments in this as well!
I did try other ACME clients with it as well (such as Proxmox's native ACME support), but Caddy was the easiest example.
I currently have mTLS running with a cert on my laptop and workstation, but I'm still not happy with the deployment and renewal process yet for end users. It's great when it works though! No more logins (if the backend software supports it)
Great stuff! It'd be great if you could also do a video on SSH certificates and how to manage them
SSH keys are a bit of a different beast (since they aren't x.509 based), but they are still using the same underlying crypto (RSA + AES or ChaCha20) and still support certificate authorities and chains of trust. It's on my todo list, but the implementation is quite a bit different than TLS certificates.
Good one. Adding to my projects list!
Hah, finally a video where I actually did the thing before you made a video on it!
Thanks for the video.
+1 for the Spaceballs reference!
Apaird never fails to impress
pfSense firewall has a CA and I generate my root and intermediate that way. Then export them to my clients.
Respect My Authoritah!
I love this channel
you are the only youtuber I watch, although the quality of your video is... crap ;-) It is probably because the content of your channel is amazing ;-)
@apalrdsadventures please look into your autofocus settings
Excellent video! Makes me thing... Maybe make a bootable USB (encrypted; maybe readonly) for the Dell WISE thin client. Easy migration etc. Have some config to write logs (syslog) to a common server, or use Kafka to keep a ledger and records of CRL and CT data.
There are a ton of options for how to better secure the CA, but in general key rotation is the most effective. This is why it issues 24 hour certs over ACME, to minimize the fallout if a private key is compromised.
-On a system with TPM2 you can secure boot your way to a validated kernel and initrd (either distro signed, or a specific image if you want, which means software updates will cause secure boot to fail), and from there you can mount the root partition (potentially encrypted via TPM also) to store the CA database (by default in Smallstep it's a BadgerDB key-value store). None of this protects your CA directly since the system is still decrypted while running (other than the Yubikey), but rebooting regularly at least means the kernel and initrd get re-validated.
-If you keep an entirely airgapped machine with the root private key, you could re-issue Yubikeys regularly and physically change them out on the intermediate CAs. If you do this monthly, at worst the attacker can issue new certs valid for roughly a month. This would involve physically swapping out the yubikey monthly if you want to keep the root machine airgapped, or only booting it up every month to remotely sign the new intermediate keys.
-Client certs (especially hardware-bound client certs) would really prefer a longer lifecycle than server certs since clients can be off-network for some period of time, so this is a consideration when you think of rekeying intervals, especially if clients need a still-valid client cert to renew.
Could you do a video on how to set up a private pki environment with OPNsense? Having a proxmox server with acme certifications etc...
Awesome video. I juts wonder: Couldn't the root cert be provisioned another way? Like via DNSSEC and and DANE?
I'm not aware of any web browsers that support DANE in 2024, so it's kinda irrelevant now.
If you use a Mobile Device Management (MDM) system such as Intune it can provision the root cert to devices for you. Otherwise you have to do it manually.
@@apalrdsadventures Thanks. Was looking for an alternative to just Intune (Am not a fan of Microsofts stuff). And who has money for an E5 or F5 license for a home lab?
There are other MDMs, but they all cost $.
thumbs up just for the spaceballs reference edit: doh! someone else beat me to it ;)
Awesome content! Subbed!
👌
yubi used to be open source - ideally people want to use their own open source hw dongles
In the end, you still have to go through every client device and import a custom root ca though, right? If not, I probably misunderstood something and that's fine. I learn more from uncovering misunderstandings.
Copying a self-signed root ca is what I used to do too but device management became a nuisance and I ended up going the reverse proxy / let's encrypt route to make things work.
Yes, you still need to import the root cert on clients. However, you only need to do this once, not trust each service separately.
I am wondering if we could use the Mooltipass instead of the yubikey...
I just got around to implementing this myself, and I'm wondering why you didn't generate the intermediate key directly on the yubikey? Instead opting to generate it on the computer and importing it?
It doesn't really matter either way. I was working with OpenSSL so I stuck with the OpenSSL cert generation workflow.
Just to nitpick a bit, aren't ed25519 sorta of prefered nowdays? And can't you just create the certificate straight onto modern yubikeys so they never have to get temp saved on a machine? :)
ed25519 is easier computationally than RSA, but the security level is roughly the same. It's widely preferred because it reduces the workload on web servers who need to sign TLS connections all the time.
For root certs, we are signing things basically never, so compatibility is more important. For intermediates, we could go either way. In very niche applications, ed25519 was never accepted (i.e. NIST FIPS requirements for government work), so generally RSA is seen as more compatible. In theory there is also stuff that only supports RSA, but in reality that stuff probably doesn't support TLS >= 1.2 so you don't want to be using it anyway.
As to generating the intermediate on the yubikey, yes, you can do that. You should still use an offline root though, with a shorter life on the yubikey, so you can replace the yubikey and sign a new intermediate in the future.
Can the OpenSSL step be skipped in favor of writing the root & intermediate keys generated by the step-ca init to the Yubikey?
I suspect that you started with OpenSSL to introduce the concepts using a tool familiar to your audience which is quite wise, but just wondering…
That should be fine. Just write the intermediate to the Yubikey, the root isn't needed there.
I see that you need to tell caddy (a webserver?) to use step-ca as you CA. I assume that you also would need to tell proxmox and all other web services/webservers to have their certs signed by step-ca (e.g., promox cluster ca would need to be configured to have its cert signed by step-ca) is that correct? Does each webservice / webserver need to be manually configured or is there a way for each machine / VM / container to be configured so that all the certs it sends out via ACME get automatically signed by step-ca?
Most ACME clients default to either Let's Encrypt or require you add the ACME server. So you'll need to set your ACME directory in the config of the ACME client.
Can we adapt your guide to utilize the step-ca docker image option for yubikey ? I have a plan to migrate my CA & other auth services to a single system in near future, but want to setup the CA server early.
I don't use Docker so that adaption is on you.
you still have to install root pem to the client
Thank you so much for this, I have one request if you can, please can you make tutorial on virtual networking inside proxmox. I have a laptop which i want to use it as my web server. It has one LAN port. I want to use that LAN port to connect to internet, then i want to have a vm (pfsense) for my networking needs (like dns and firewall), then finally i want my other vm's (like website, storage server, jellyfin etc) to connect to the pfsense server and to internet eventually so that all of it can be accessible over internet anywhere. Can you please make a video on it like a casestudy or can you point to a guide or anything. Please Please please.
I have a tutorial on basic Proxmox networking (vlans, bridges, and bonds) and I’m working on new episodes with backend and SDN networking.
@@apalrdsadventures i saw that and that really helped me understanding those concepts. I was only using vlans prior to that. But what i am not able to understand is how to fit those concepts for my use case. Can you help me?
Help, I’m stuck step CA!
Hey Dude!I am on a similar path at work .. Considered adding SSH signed keys?
Working on a good way to deploy client TLS certs, then I'll work on SSH certs with the CA
@@apalrdsadventures Personality doing the key distribute with cfengine - ce. Bit of a B to learn but now I love it!
Why not put the root CA on a YubiKey? What about YubiHSMs, would those be any better/different for this?
With only one Yubikey in my setup, the goal is to keep the root totally offline (it has an extremely long validity) and periodically bring it out of offline storage to re-sign the Yubikey. This works well at this scale. Of course, the root could still be a Yubikey itself that I just plug in every time I need to re-key.
The Yubikey itself is adequate to store a small number of certs/keys in hw and do some operations on them. The YubiHSM can store a lot more keys in hw, provide multiple access with different permissions to each key, supports Microsoft AD CA directly, and has built-in audit logging. So it depends on your needs.
So theoretically, having four yubikeys, one could create their root on one, sign three intermediates (or more if needed of course), and then use as needed? I believe the only caveat I found with using a YubiKey as the root storage is the size limitations. It won't go to 4096 RSA. That might be the main blocker for some wanting that route I guess.
IIRC, YubiHSM has the same size restrictions, just more slots and control as you mentioned?
I honestly may just look to getting some encrypted drives to store the private key, do all the offline isolated magic as you have, and have flexibility to move the key as I see fit. Good example could be flaws found in YubiKeys and replacements offered. Sure, you have the latest firmware, but zero way to truly upgrade to the patched one. Only replace.
Thanks!
You did a great job at imitating IT-Crowd-Roy's appearance, that hairstyle and neckbeard is just perfect.
Have you considered an alternative to Yubikey?
An intermediate key added as data to a PNG file.
PNG file with any graphic (e.g. cat) and any name (e.g. cat.png) saved to usb flash drive.
The file browser treats this PNG file as a typical photo.
When debian detects the PID:VID of this usb flash drive it extracts the intermediate key from the PNG file.
(udev script)
I think you understand what I mean?
The downside to this is you can export the private key from a flash drive, so the extracted key file could be compromised. The Yubikey can't export the private key, only sign in hardware using the key.
Smallstep also supports PKCS#11 HSMs including the TPM2 standard, which could be a good option on modern systems. But the Yubikey 5 is the cheapest HSM which Smallstep supports as far as I know.
@@apalrdsadventures
If the private key was encrypted with a password generated from a checksum generated from another flash drive serving as the password for that encrypted key, would it still be a bad idea?
Ultimately the key needs to be decrypted to be used, so the information necessary to decrypt it is available to an attacker on the system. Would they figure it out? Maybe, maybe not.
@@apalrdsadventures
If, in my example, I lose the second flash drive and do not write down its checksum for myself in a safe place (I would use SHA512) then I will not get to the private key.
The attacker would have to figure out that the password is the checksum of the second flash drive.
The attacker would probably start by reading the Smallstep config file and finding where the private key is supposed to be stored, then looking for a key file in that location (presumably decrypted on boot into a RAM disk so Smallstep can use it). Ultimately, Smallstep needs to sign things and by reading the config file you can work backward to find the key / the script that loads the key on-demand.
I would be much more inclined to run my own CA like this if its root certificate had a flag indicating it was only valid for a certain domain. Unless I've missed some new developments in the PKI system this isn't possible. If a bug results in my CA signing a rogue certificate for Google then suddenly I can no longer trust connections to Google.
Google pins their certificates and Chrome won't accept imposter certs for Google domains.
@@killer2600 I was using Google as a standin for any important website.
Can we convince Nginx Proxy Manager to use our CA using ACME to issue new certificates?
It looks like they don't have an option to do that easily in their gui
@@apalrdsadventures then I will try in the main config, this looks interesting.
Is it possible to use a smartcard instead of a YubiKey ?
Should be the same (in this scenario yubikey is treated as Smart card anyway)
If anyone managed to compile step-ca for arm64, I'd appreciate to learn how you did that.
My attempts at step-ca cgo builds fail with 'no such instruction' errors.
Looks like building this on a RPi is out for the moment.
The official guide from step-ca is on a pi. I just followed it and compiled without a problem.
Aww sorry this is so cool but the fact that you need to do something in every client device (in this case trust the root cert) kills the whole idea.
In my case I bought a domain name, then proceed to generate a wildcard cert with lets encrypt using a dns challenge and done.
But knowing all the process is great! thank you
There are a lot of uses for certs other than TLS server certs - for example I use this setup for TLS *client* certs, but it's also commonly used with VPN or WiFi certs for example.
I dont get the point of this. If someone hacks the server, they may not be able to get the key, but they will still get all the important functions of the key because the yubikey secrets are store plainly on the server. So they you wont be able to trust certs signed by that cert. And unless you have a good way of doing certificate revocation lists, you'll in practice need to untrust the root CA anyway.
It could be argued this protects against physical key theft but even then its only if the server's yubikey secrets are encrypted and the server is otherwise locked down (no console). Most home servers don't meet that.
So in summary this seems to only inject complexity and unnecessary software into the public key infrastructure.
The root cert is stored offline after it's created, so only the intermediate cert is on the CA system at all. So now we have a shorter lifetime (1yr intermediate vs basically infinite) to begin with, which limits the length of an attack. You can reduce this time down further if you are willing to re-key the yubikey more often.
Next, the Yubikey can't export it's private key, so while someone could sign their own certs using the Yubikey, they can't steal the private key itself, so they are limited in how fast they can sign new certs. If they are going through step-ca, it will only issue certs with a ~48hr validity, so that's the limit of what an attacker could get. If they manage to hijack the system entirely, then they could issue certs up to the validity of the intermediate cert on the Yubikey.
All of this makes the PKI more secure than keeping the root cert on a server somewhere.
@@apalrdsadventures Thanks for responding. I agree with the benefits you mention but not sure I agree that they are valuable in a homelab. But I can imagine some scenarios that would benefit depending on what threats one is worried about.
17:31 pretty certain the comment on the website is wrong ? "not the public keys", I assume you meant: "not the private keys".
21:45 might be a better idea to have the CA HTTPS SSL cert issues by Let's Encrypt or other trusted CA. To make sure what you are downloading is more likely to be correct.
Thanks! Fixed it! The command was correct, just the comment was off.
Yeah ! Great to hear you are going to do mutual-TLS ! Great stuff !
Some other tips: set up OCSP and/or CRL as well. Short lived keys is already a good start, but my guess is this won't be practical for the clients...?
The hard thing with CRLs/OCSP is most clients don't actually use them. But for mtls, I can at least force Caddy to query it (I think, I haven't tried). Currently for testing I issued 2 month certs for my test clients, but I'm not a huge fan of that.
My *hope* was to use hardware-bound keys on clients to avoid the need for short-lived keys, but testing with Yubikeys it's a bit of a pain (Firefox makes you retype the PIN every few minutes) and Apple doesn't allow their hardware-bound keys to be used aside from with mobile device management apps. So now I need a new plan.
For 'on-network' clients a few days cert and automation to renew would probably be fine, but more transient devices might still not be on once a week.
@@apalrdsadventures what I've done for now, I used it only for checking the status of the client-certificates for authenticating to the servers. So when I need to revoke a client-certificate (not often): I add the revoked client to the CRL-file signed by the CA and update the CRL on each server by hand. Not pretty, but at least it doesn't depend on an OCSP server being online, etc.
Is it possible to have 2 internal certificate authorities?
Yes, but why? A given service can only use certs issued by one authority. Clients can trust any number of authorities.
It’s also possible to issue 2 intermediates from the same root if you want multiple locations or redundancy.
@@apalrdsadventures not required, but one of the self-given challenges for my homelab is building unnecessary redundancies where possible
You can use the single offline root key to generate multiple intermediates for redundancy (on multiple yubikeys / ...), and then host multiple CAs using an intermediate key for each. All of them are signed by the root, so there's one hierarchy, but you can issue leaf certs from any intermediate.
@@apalrdsadventuresit's possible to have 2 roots, you send the csr to be signed by different authorities, ones that's done the cert is trusted by both due to them having the same public key. This is how let's encrypt recent rolled over to a new root without needing to resign certs
Let's Encrypt signed their intermediate cert with two roots, ACME clients aren't really designed to issue from two CAs at once. You could do the same and sign the intermediate cert from two roots, but if you are looking for redundancy it would make more sense to replicate at the intermediate level (however you choose to do that)
I have no idea how I got here
Burn the book if you dont like the answers
Flash storage has a shelf life of approximately 1 year without being rewritten
NGL, you can skip the "attention grab" at the start, we know what this channel is and I clicked on the video bc the title had something I want to learn.
when i run sudo -u step step-ca /etc/step/config/ca.json
i am getting below error. how to solve it?
authority.GetTLSCertificate: error creating certificate: x509: requested SignatureAlgorithm does not match private key type