I understand a fair bit about keys in regards to what the private key does, and the public key for technologies such as PIV and GPG.

Where I get lost is how the certificate comes into play and what you're supposed to do with it.

For example, the private key is obviously yours and you use it to decrypt messages or files related to GPG that are sent to you. Your public key is what you give other people or upload to a public keyserver so that people can send you encrypted messages.

But aside from the public and private keypairs, there's also an option in software such as Kleopatra to generate a CSR for my GPG Keys.

  • What is the purpose of generating that CSR if I have the private / public keys already.
  • What do I do with that CSR if I do generate one? Do I hold on to it and keep it private like I would my private keys?
  • What's the different between an x509 certificate that can be generated for PIV, and a certificate I can generate for GPG. Are they the same thing? x 509 certificate? Just different technologies use to generate them?

If you're confused about PIV, I'm referring to Yubikeys. They contain two interfaces that appear to do similar things: PIV and GPG.

And to clarify, I don't have a CA, I am generating a self-signed certificate.

And I guess the bonus question I have because I seem to be finding no clear answer, what's the difference between exporting a CRT, CSR, and say a PEM.

I found an explanation here: https://crypto.stackexchange.com/questions/43697/what-are-the-differences-between-pem-csr-key-crt-and-other-such-file-exte

But some of the definitions don't register with me. Maybe over-complicated for my limited knowledge?


  • I'd suggest you to split the question into several posts: 1) About CSR; 2) About formats; 3) About Yubikeys.
    – mentallurg
    Jan 30, 2023 at 21:51

2 Answers 2


What is the purpose of generating that CSR if I have the private / public keys already.

The problem with a raw public key is that it says nothing about who owns the private key. I can use it to send and receive encrypted communications from you, but I need a separate trusted channel by which to verify you are who you say you are.

That's where certificates come in. A certificate is a combination of a public key and metadata about that key such as who owns the private key and what it's supposed to be used for. This metadata can then be signed by a trusted third party who has verified that you do in fact own the private key and that the metadata is correct.

This way, you can send me a certificate and I can both read your encrypted messages and verify, via a trusted third party, that you are who you say you are.

What do I do with that CSR if I do generate one? Do I hold on to it and keep it private like I would my private keys?

A CSR, or Certificate Signing Request, is the same public key and metadata that would be in a certificate, but without a signature. This is what you generate and send to a certification authority to have signed and turned into a certificate.

If you don't use a CA and self-sign your certificate then you're giving up most of the benefits that a certificate provides in the first place. The CA is the trusted third party who verifies that you are who you say you are. Without one there's no way to verify that the metadata in the certificate is accurate.

Regarding your bonus question:

  • PEM is just a text-based wrapper for transferring binary data over channels that don't like non-text data. This is useful for, for instance, embedding a PGP signature into an email. It's formatted like this:
-----BEGIN <thing>-----
<bunch of data>
-----END <thing>-----

Pretty much anything can be wrapped in PEM, but it's used primarily for cryptography-related data such as keys and certificates.

  • CSR is, as mentioned above, short for Certificate Signing Request. These may or may not be wrapped in a PEM text encoding. Different software will support different formats.
  • CRT is a certificate. Again, this may or may not be wrapped in PEM text encoding. As for CSRs, different software will support different formats.
  • This makes way more sense now. So you have a public key and private key. The certificate is what verifies where that public key came from and verfies the owner, along with data about the person who owns the key. Name, city, state, etc. The certificate is what you send off to a CA to get verified. Correct? I guess the question is does the person you're encrypting data to with your GPG Key ever need your certificate? Or is that certificate strictly for you and the CA so that they can verify / certify that you are who you say you are.
    – Arthae
    Jan 30, 2023 at 23:50
  • You don't send a certificate to the CA, you send a CSR and they send you back a certificate (assuming they can verify the claims in the CSR). That certificate contains both your public key and the metadata about who you are, so you can now send the certificate to anyone you want to communicate with and they can use it to both encrypt/decrypt communications and verify you are who you say you are (assuming they trust the CA). Jan 31, 2023 at 2:15
  • Ok, I think I get it now. I guess my last question would be, I'm not using my keys for corporate type work. I am an independent developer who just wants to sign my code and guarantee authenticity. What type of CA should I go with? I've seen some CAs asking upwards of $100+ to get a certificate, and I'm not sure if that's the general ballpark for them, or if there's some better for small independent people.
    – Arthae
    Jan 31, 2023 at 4:53
  • I'm not familiar at all with getting certificates signed for uses other than HTTPS. If you're just looking for some assurance that your code is yours then configuring Git to use a GPG key to sign your commits and uploading that key to your GitHub account is enough to ensure that you, the owner of the account, did actually author the code. It doesn't provide any assurance that the name on the account is accurate, but the fact that you have the login credentials should be enough to link you to that account. Jan 31, 2023 at 16:02

What is the purpose of generating that CSR if I have the private / public keys already.

If you send your public key to somebody, how will one know that this is really your key? There can be a man-in-the-middle sitting between you and another party who intercepts you traffic and send own public key instead of yours and vice versa. A certificate proves that particular public key really belongs to you.

Certificates are issues by certification authorities, CAs. Before issuing a certificate, a CA checks the claims that you requested, e.g. if the email address belongs to you (for S/MIME certificates), if domain name belongs to you (for TLS certificates), postal address and others (for extended validation certificates).

To obtain a certificate, you send a request to CA. Such request is named CSR, Certificate Signing Request. You request that the CA issues and signs a certificate that confirms that the given public key belongs to you. This request contains fields that you want to have in your certificate, like the name, validity period. To prevent that anyone requests certificate for given public key, this request must be signed by a private key that matches the public key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .