While increasing my communication security as much as possible, I came across OpenPGP & S/MIME and already use an OpenPGP key pair in both of my mail clients (PC & smartphone).

I believe the CSR must be generated based on a truely private key, hence a CA generated one is unacceptable for me. Unfortunately, I struggle with finding the correct OpenSSL arguments needed for CSR generation based on my existing OpenPGP's public key instead of letting OpenSSL create an entirely new key pair.

Put simply, how to tell OpenSSL: "Take Thunderbird's 'Armored ASCII'-formatted public key export file & create a CSR based on it (and further provided details like CN, O, OU, etc.)"?

  • "I believe the CSR must be generated based on a truely private key, hence a CA generated one is unacceptable for me." - This makes no sense.
    – user163495
    Sep 28, 2020 at 13:17
  • It does, but maybe I explained my goal wrongly.. I tried to explain that a CA, generating both keys in order to create the CSR afterwards for me, is unacceptable for me, even if they state "keys only generated in browser, undisclosed to CA, etc." - I'd happily accept being called "paranoid" for this POV, but that's how I see private keys and their generation.
    – Yoda
    Sep 30, 2020 at 21:59

2 Answers 2


So, I'll admit, OpenPGP is not something I have much more than a superficial knowledge of. I always end up back in the docs when I have to explain something - it's just not a useful technology for most of what I do (web app development in the cloud).

Go/No-Go Decision

Mileage will vary, somewhat, depending on your key type. The CA will have a specific set of key types (encryption algorithm + key size) that it will accept. That's non-negotiable. If the OpenPGP key that you have is not of an acceptable type, then you won't get far with this procedure.

Getting the Key

Next, I would expect that you need some way to transform the OpenPGP key into a format that can be used to sign the CSR... unless it's already stored in a vialbe format.

I haven't tested it, but this looks like a reasonable procedure:


What I can't tell is what format this will export the key into. Ideally, it'll have a nice clear file extension (.der, .pem, .p12 or .pkcs12 are all common formats that would fit with the notes in the next section).

Making the CSR

For Open SSL CSR generation, the command is nicely discussed here:


The core of it being:

openssl req -new -key key.pem -out req.pem

"key.pem" being your pre-existing key. The PEM describes a way that a private key can be encoded. DER and PKCS12 are also common formats, and converting between formats is described here:


Open SSL being what it is, I would expect you could also use any of these 3 formats directly in CSR gen, though you may have to give some argument to specify which format.

... But should you

As I was writing this, the angel on my shoulder had some things to say. It's one thing to be able to do this. It's a different question of whether you SHOULD. Private keys are the essence of security in asymmetric cryptography and handling them in a less secure way can compromise the protection.

I think this may be a case where you are better off doing this the easier way and generating a new private key for your CSR instead of trying to reuse your PGP key. I don't have all the context, so I can't say for sure. Instead, here's some things to think about:

  • Non-repudiation - the concern mentioned in the question about having a "truly private key" speaks to the idea that you want to have only your 1 system in control of the key. In the sketch of the procedure above - you are making a copy of the key in exporting it from PGP. You may also have a second copy in converting it's format for OpenSSL. At the very least, be sure to clean up any extraneous copies. But you'll likely end up needing 2 copies - one for the OpenPGP use and one for the purposes for which you are signing a certificate.

  • Limiting exposure risk - if you use the same key for two purposes and it's exposed, it compromises BOTH purposes. That doubles the risk of exposure of cryptographic content. If you had 2 keys and only 1 was exposed, the risk would be smaller. For this reason, often different key is used for different purposes.

  • Ease of renewal - key expires. Being able to rotate key easily (automatically!!!) minimizes the risk that you'll loose connectivity when the certificates that represent the key expire. By connecting the Open PGP and the Certificate's private key - you make your rotation process more difficult, as you have (1) generate new key, (2) re-authorized the PGP side, (3) cut a new CSR, (4) get a new certificate. That means you are almost certainly scripting something to do this, instead of telling each side to auto-renew on it's own.

I would argue that having 2 keys for these two separate mechanisms on the 1 system is not less secure. Either way, the key is sitting on your hard drive, and could even be sitting in the same key storage system/drive location and thus afforded all of the OS level, hard drive level protections available on your computer.

Reasons that you would want to keep the key the same:

  • Trust distribution challenges - I have seen systems that would accept the authority of the PGP system or PKI hierarchies, and thus, your application must distribute a marker for it's key pair - and that single form of identity is how your system is authenticated. I can't really think of why you would have such a situation that requires both PGP and X509 credential creation... but never say never. If you are working in a system that imposes this restriction, then you're stuck trying to do what you're asking to do.
  • Suitable key generation is deemed a serious risk and as such, is very difficult. The case that comes to mind is if you are hardware protecting your key, then getting access to the device that creates and keeps your key (not on your hard drive!) - can be difficult. Doing it twice can be twice as difficult. I've worked on a fair number of high level FIPS devices like this, and I'd still probably be inclined to make 2 different keys on that device, and use them for the 2 purposes... but mileage could definitely vary.

That's probably not a final list of either pros or cons. But I'm hoping that it gets across that 1 key for all purposes is not necessarily more secure.

  • 1
    Thanks so much for this valuable information, it helped a lot to understand things way better than before! :) Now, as commented on @dave_thompson_085's answer, I'm uncertain if 2 private keys aren't even better considering OpenPGP key extension after several years as you suggest to me that it'd require immediate cert renewal (even if done just 2 months before). Also, the private key is already copied as I'm using it on PC and phone (with web-based mail access being added to my NAS shortly, too), so 2 keys are definitely better, aren't they?
    – Yoda
    Sep 23, 2020 at 8:34
  • 1
    I'm not willing to give you a final one true answer on this. I believe I laid out the pros and cons in the second half of my answer. I'd think that 2 keys are better in most generalized cases... but I can think of cases where 2 keys are a no go - which is what I outlined in the "reasons to keep the key the same" bullets. If those didn't apply to me, then I'd definitely lean toward 2 keys. Sep 28, 2020 at 20:00
  • Thanks, that helped to make my final decision! :)
    – Yoda
    Sep 30, 2020 at 9:35

You can't generate a CSR using only a publickey, you need the privatekey, which for historical reasons PGP calls the 'secret' key. Also once you get a cert, to do anything useful with it you need the privatekey. (Both PGP and OpenSSL-compatible privatekey file formats include the publickey, so you don't need that separately, although depending on the software you use, you may need a separate file for the certificate, and maybe more for any chain/intermediate certificates needed for the CA you use.)

There is a (bizarre!) workaround via gpgsm found at https://superuser.com/questions/435321/how-can-i-export-public-keys-in-pem-format-with-gnupg which actually got it from http://sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG%2C-OpenSsh-and-OpenSSL#c21688 :

  1. Since Thunderbird actually uses GnuPG (which since 2.0 at least includes gpgsm) you don't need to export anything from Thunderbird. Instead find your (sub)key in the list shown by gpg -K --with-keygrip . It must be an RSA key; this operation doesn't work for other algorithms.

  2. use gpgsm --gen-key -o tempcert with option 2 and the keygrip shown by gpg (note the keygrip not the fingerprint, they are different), enter something for the requested identify info (it doesn't really matter what), and y to create a self-signed certificate.

  3. gpgsm --import tempcert and gpgsm -K to get the (new) keyid.

  4. gpgsm --export-secret-key-p8 -a -o $p8file $keyid; this produces a PEM-format privatekey OpenSSL can use (PKCS8).

  5. openssl req -new -key $p8file etc as usual

Altenatively, what I personally would do is write a few lines in Java using BouncyCastle bcpg for the PGP side and bcpkix for the S/MIME-or-OpenSSL side. I did the other direction (PEM to PGP) at https://unix.stackexchange.com/questions/276317/how-can-i-import-a-key-in-pem-format-not-openpgp-into-gpg that shows the ideas.

  • Thanks a lot for the walk-through, much appreciated! Though, @bethlakshmi 's answer made me uncertain if 1 private key is actually wise or if I'm better off with 2. Especially key expiry extension via TB's UI and her hint regarding S/MIME cert renewal created that uncertainty as it seems key extension and cert renewal must be timed together, i. e. "key extension for 2 more years = repeat walk-through above, submit CSR, get new S/MIME cert, import into TB" while sticking with 2 private keys would mean "generate only once, renew cert once in a while & import into TB"
    – Yoda
    Sep 23, 2020 at 8:26
  • 1
    It's up to you. She has a point that if each program is set up to manage its own keys automatically or at least conveniently, as is usually the case for 'end-user' products IME, using those procedures (and thus separate keys) is easier to carry out -- and offers less opportunity to make a mistake. And there's no particular benefit to using the same key for different formats/protocols, although it is technically possible, since PGP peers will use only your PGP (format) keyblock and SMIME peers will use only your SMIME (format) cert. The trust is not shared even if the key is. Sep 28, 2020 at 7:58
  • 1
    Do hers. Normally I'd feel obliged to parrot Stack policy about assessing the comparative utility to children not yet born blah blah, but this method is just so weird I got more fun out of finding it for myself than I possibly could from answer points :-} Sep 30, 2020 at 7:00
  • 1
    About half a joke. It is true Stack's stated goal for voting is to select the 'best' Qs&As to be presented to people who search in the future, with the intent they will be useful -- ideally, solve the new problem with an already-existing answer. But future children was an exaggeration by me; given the rapid changes in computing, I doubt very many Stack posts will be useful more than a decade, and quite a few substantially less. Cheers. Oct 2, 2020 at 9:34
  • 1
    I was half-stuck in the middle of your step-by-step explanations when I also came across a small tutorial on generating certificates from PGP keys Also, CAcert suggests using the openpgp2ssh tool from the monkeysphere project to make the whole process a bit easier. Hopefully, this may be useful to others stumbling upon this question. Nov 18, 2021 at 20:43

You must log in to answer this question.

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