3 ms·

How do you issue client certificates? Do you not worry that the private key needed to issue these can also leak just the same as your personal private key?

by xyzzyz 4y ago

cubesnooper 4y ago
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.
blablabla123 4y ago
By doing a Certificate Signing Request (CSR) from the client. Not sure when it's actually worth doing this extra effort but with the right automation (e.g. with Ansible) it's doable. Never tried this for ssh though. Additional security if you use HSMs.
- xyzzyz 4y ago
  That actually doesn’t answer my question (though the actual addressee answered it already quite satisfactorily). First, there is no such thing as CSR in context of ssh certificates: ssh certificates are not x.509 certificates (known for their use in TLS). Second, even assuming that they were, a client creates a CSR with their key, and then what? Where is the root of trust? Who processes these CSRs? How is it deciding which CSRs to accept, and which to reject? That’s what I’m actually asking about.
  - blablabla123 4y ago
    I mean ssh certificates can be x509, Azure VMs used to be provisioned with PEM actually, also PGP can be used. Not sure, I guess a use case could be to create client certificates remotely that are part of a certificate hierarchy. Obviously this doesn't solve any root of trust issues if the creation is initiated by the client.
- cubesnooper 4y ago
  SSH provides native support for certificates; they’re a custom (non‐X.509) format. The signatures are generated with the ssh-keygen command; I set my infrastructure up purely by reading the manpage, not referring to any blog posts or anything, so I think the documentation is a good way to get started. https://man.openbsd.org/ssh-keygen.1#CERTIFICATES https://man.openbsd.org/ssh-keygen.1#CERTIFICATES

How do you issue client certificates? Do you not worry that the private key needed to issue these can also leak just the same as your personal private key?

by xyzzyz 4y ago

How do you issue client certificates? Do you not worry that the private key needed to issue these can also leak just the same as your personal private key?

cubesnooper 4y ago

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.

blablabla123 4y ago

By doing a Certificate Signing Request (CSR) from the client. Not sure when it's actually worth doing this extra effort but with the right automation (e.g. with Ansible) it's doable. Never tried this for ssh though. Additional security if you use HSMs.

xyzzyz 4y ago
That actually doesn’t answer my question (though the actual addressee answered it already quite satisfactorily). First, there is no such thing as CSR in context of ssh certificates: ssh certificates are not x.509 certificates (known for their use in TLS). Second, even assuming that they were, a client creates a CSR with their key, and then what? Where is the root of trust? Who processes these CSRs? How is it deciding which CSRs to accept, and which to reject? That’s what I’m actually asking about.
- blablabla123 4y ago
  I mean ssh certificates can be x509, Azure VMs used to be provisioned with PEM actually, also PGP can be used. Not sure, I guess a use case could be to create client certificates remotely that are part of a certificate hierarchy. Obviously this doesn't solve any root of trust issues if the creation is initiated by the client.
cubesnooper 4y ago
SSH provides native support for certificates; they’re a custom (non‐X.509) format. The signatures are generated with the ssh-keygen command; I set my infrastructure up purely by reading the manpage, not referring to any blog posts or anything, so I think the documentation is a good way to get started. https://man.openbsd.org/ssh-keygen.1#CERTIFICATES https://man.openbsd.org/ssh-keygen.1#CERTIFICATES