Is it possible to use an already created key pair?

Will it be possible to use an key pair (certificate) which you already have generated? So that LE doesn’t generates a new self-signed cert when using, but use your own already generated cert?

Hmm, if you already have a certificate, just keep using it until it expires
and then create a new one via Let’s Encrypt. Or just create a new one to
replace it when Let’s Encrypt is up and running…

No I mean no CA-signed key pair. Just a local self-signed key pair.
So if I want to use it and let it sign by Let’s Encrypt? (like a normal CA does) Is that still possible?

I mean is there a command of the client to use an already generated key pair?

Hmm, here you have an scenario where what @rugk ask could be needed:

I have a Mail-in-a-Box running over a DigitalOcean server that acts as a DNS Mger. for all my domains, running under and IP to be cosidered the ‘master’ SERVER01. deboted to manage ALL domains Mail accounts and their DNS. No web to be served here.

I could have a LECert already created at SERVER01 for multi-domain support as follows:, www, and

  • & www. will be pointed through an A DNS records to SERVER02 with IP, Then the possibility to import the LECert created earlier is a must.
  • will be pointed through an A DNS record to SERVER03 with IP, Then the possibility to import the LECert created earlier is a must, too.


A) Importing a multi-domain LECert to a different server will be available?

B) Importing a multi-domain LECert to a different server will not be available then… will we need to create a separate LECert for each subdomain and necessarily create each one under their assigned CLOUD server?

Note: Congratulations! for this amazing project :smiley:

1 Like

Not sure about the original question. But in terms of multi domain certs, AIUI you’ll need to create a separate certificate for each domain and just like any SSL certificate, when you have it, you can put it on any relevant machine.

I think what he’s asking is - will the LE client support retrieving a certificate given a CSR, and not generating a whole new key + CSR.

For moving the cert from one server to another - that shouldn’t need to involve the LE client at all - would just use normal export/import mechanisms for the key+cert to bring over to the other machine in the cluster/etc.


That’s exactly what I try to ask and much better explained… Thanks a lot!

Yes that's exactly what I am asking.

Yes, but that's not the reason I'm asking.

And @just4t I also don't know what your question had to do with my inital question.

@rugk Easy! Seems that's exactly what your question and my question have in common. isn't it?

  • Just we need to wait for a final answer/ confirmation.

So let me explain why I’m asking this:
If you’re using a technology, called [HPKP] (, which hardens TLS connections by only allowing a specific set of certificates to connect to the domain later.
Because this can be dangerous (if your used cert is compromised e.g.) you have to generate backup certificates. These ones only are a key pair and don’t need to be signed by a CA at the time when you create them.

So and if we later want to switch to Let’s Encrypt we have to one of these key pairs. Otherwise visitors of the site would get errors and can’t connect to the site any more.
Of course we could try other things like generating a new LE cert and include it in the header for some time and wait (hopefully long enough) until the last user has received the new header (or the old header has expired), but this is not optimal as it can probably end badly and not really something I’d like to do if I have other - much easier - ways.

So principally I’m just asking whether LE can also work like a ‘traditional’ CA, where I can give it a .key and .csr file (or only a .key file as it can generate the .csr by itself).
So e.g. doing it like this:

letsencrypt -keyin ./mycert.key auth

The protocol certainly supports that. Not sure if it’s available in the client at the current time.

1 Like

@just4t No I don’t know why you would want to generate the local cert by yourself. You can just let it generate by Lets Encrypt (also the private one), maybe with multiple domains if you like, and put it on the machines you like.

@riking’s right: The protocol supports it. I’m not sure if the client currently does, but it’s definitely a useful feature, so if it’s not supported today it very likely will be in the future.


I hope we will be able to sign csr files generated manually. The LE app shouldn’t need to have access to any private keys. That is the whole point of keeping the signing process secure.

1 Like

@jsha, the client currently does support it in some form. We’ll need to have some more work on the interface and documentation for this case, but it’s something that’s already there. So the answer to the question is yes, you can use your own existing key that you generated outside of the LE client and get a cert for that key.


@philios33, it is possible to use an externally-generated CSR with the Let’s Encrypt client. This should work in the most common use cases without direct access to the private key.

I’m not clear on why it would be especially dangerous in most use cases for the Let’s Encrypt client to have access to the private key. The client is open source software written in Python and distributed as Python source code to run on your own server. You can look at it yourself to confirm that it doesn’t do anything improper with your keys. If you let OpenSSL (a vastly more complicated piece of software) read the private key in order to generate your CSR, perhaps you could accept letting the LE client read the key on the same basis (including the likelihood that you can get the LE client from your operating system distributor).

But yes, there’s no requirement in general to let the client read your private keys. You may need it for some CA operations (such as issuing a cert where there is already an existing cert for the same domain in use on the Internet), but there should ultimately be options to do everything manually or with your own software if you prefer, including by writing your own code to implement the ACME protocol.


@schoen Excellent, thanks for the info.

Ultimately it is a trust issue because not many people would look at the source. Keeping the client code secure is going to be very important to keep the CA trust. The part i’m sceptical about is making it easier for users by bridging that gap that we have now for CSR signing. The party that generates the CSR should be separated from the signing authority. I think people will view the LE client as a middle-man which they need to completely trust to use the system.

The fact that it needs root access for it to work properly (OpenSSL doesn’t) does not help matters either. Hopefully everything will go fine and trust will be built up over the coming months/years but I think it’s a very fragile system. One code exploit or dodgy distribution and you’re looking at complete revocation of the LE CA certificate and possibly the end of the system.

Maybe i’m just being paranoid though. I guess you need to trust some code at some point along the lines. Afterall, it’s code that is trying to help.

Related/More information:


What I’ve done (for postfix and vsftpd that need the key) is ln -sf the 000?_key-letsencrypt.pem to something fixed (/etc/letsencrypt/keys/letsencrypt_static.pem) and in my cron script to update the certs I find the last-written file inside /keys and change the symlink to that one.