3 ms·

I have a Raspberry Pi dedicated to generating certificates. It serves the files to my LAN statically via a webserver, and is otherwise heavily firewalled. I don

I have a Raspberry Pi dedicated to generating certificates. It serves the files to my LAN statically via a webserver, and is otherwise heavily firewalled. I don't run any other software on the Pi, so barring an exploit in the webserver, I’m not worried about the signing key getting compromised. Compared to my desktop, where over the years I ran all kinds of stuff from the package manager, downloaded Python scripts and configure scripts from GitHub and Sourceforge… I tried to be careful but you can’t audit everything.

xyzzyz 4y ago
So anyone on your LAN can visit the URL and download the CA private key? Isn’t it only marginally more secure than just keeping the private key on your workstation in the first place, and foregoing the entire rigamarole with certificates? I mean, if you are worried about your something compromising your workstation and stealing your individual private keys, nothing is stopping whoever compromised your workstation from asking your RaspberryPi nicely for CA signing keys and stealing those too.
- cubesnooper 4y ago
  > So anyone on your LAN can visit the URL and download the CA private key? No, the only files served to the LAN are the certificates, which contain the signatures by the CA of the public keys of other machines. Those are safe to distribute openly because they’re useless without the private key of the public key that was signed.
  - xyzzyz 4y ago
    Okay, so let me make sure I understand it. You have your own personal key, and CA key. Your personal (private) key lives on your workstation, and CA key lives on RPi. There are some other machines that you want to SSH into. They trust CA public key. To log into them, you download client certificates for your personal key, signed by CA key, from the RPi, and present them to remote SSH servers, while proving to them ownership of private key corresponding to the certificate. The remote servers trust the certificate issuer, verify that you own the certificate’s private key, and let you in. Do I get it correct? If so, how do you issue the certificates that live on RPi? Those certificates have some limited validity period, so that you can worry less about leaking them, which was your concern in the first place. Therefore, you must reissue them on a regular basis. How do you do that? What’s your process for that?
    - cubesnooper 4y ago
      > Your personal (private) key lives on your workstation, and CA key lives on RPi. Yep. > There are some other machines that you want to SSH into. They trust CA public key. Yep, with TrustedUserCAKeys. > The remote servers trust the certificate issuer, verify that you own the certificate’s private key, and let you in. Yep. Additionally, the servers themselves present CA‐signed certificates alongside their host keys. My GlobalKnownHostsFile contains the CA public key, so when I connect to a host for the first time, there’s no “unknown host” warning and my user’s known_hosts file is not updated. > If so, how do you issue the certificates that live on RPi? The CA has a directory containing the public keys of every user and host that I set up. A cronjob periodically runs ssh-keygen -s against these files, and copies them to htdocs. Each host and user has a cronjob that periodically fetches its certificate and copies it to /etc/ssh or ~/.ssh, respectively.
      - xyzzyz 4y ago
        Ah, now I understand. That makes total sense. Thanks for your detailed explanation.

xyzzyz 4y ago

So anyone on your LAN can visit the URL and download the CA private key? Isn’t it only marginally more secure than just keeping the private key on your workstation in the first place, and foregoing the entire rigamarole with certificates? I mean, if you are worried about your something compromising your workstation and stealing your individual private keys, nothing is stopping whoever compromised your workstation from asking your RaspberryPi nicely for CA signing keys and stealing those too.

cubesnooper 4y ago
> So anyone on your LAN can visit the URL and download the CA private key? No, the only files served to the LAN are the certificates, which contain the signatures by the CA of the public keys of other machines. Those are safe to distribute openly because they’re useless without the private key of the public key that was signed.
- xyzzyz 4y ago
  Okay, so let me make sure I understand it. You have your own personal key, and CA key. Your personal (private) key lives on your workstation, and CA key lives on RPi. There are some other machines that you want to SSH into. They trust CA public key. To log into them, you download client certificates for your personal key, signed by CA key, from the RPi, and present them to remote SSH servers, while proving to them ownership of private key corresponding to the certificate. The remote servers trust the certificate issuer, verify that you own the certificate’s private key, and let you in. Do I get it correct? If so, how do you issue the certificates that live on RPi? Those certificates have some limited validity period, so that you can worry less about leaking them, which was your concern in the first place. Therefore, you must reissue them on a regular basis. How do you do that? What’s your process for that?
  - cubesnooper 4y ago
    > Your personal (private) key lives on your workstation, and CA key lives on RPi. Yep. > There are some other machines that you want to SSH into. They trust CA public key. Yep, with TrustedUserCAKeys. > The remote servers trust the certificate issuer, verify that you own the certificate’s private key, and let you in. Yep. Additionally, the servers themselves present CA‐signed certificates alongside their host keys. My GlobalKnownHostsFile contains the CA public key, so when I connect to a host for the first time, there’s no “unknown host” warning and my user’s known_hosts file is not updated. > If so, how do you issue the certificates that live on RPi? The CA has a directory containing the public keys of every user and host that I set up. A cronjob periodically runs ssh-keygen -s against these files, and copies them to htdocs. Each host and user has a cronjob that periodically fetches its certificate and copies it to /etc/ssh or ~/.ssh, respectively.
    - xyzzyz 4y ago
      Ah, now I understand. That makes total sense. Thanks for your detailed explanation.