Getssl -> certbot


Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:,,

I ran this command: certbot certificates -d --logs-dir /tmp --config-dir /tmp --work-dir /tmp

It produced this output:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
No certs found.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

My web server is (include version): Apache/2.4.34

The operating system my web server runs on is (include version): Ubuntu 18.04.1 LTS (kernel rev 4.17.8-x86_64)

My hosting provider, if applicable, is: Linode

I can login to a root shell on my machine (yes or no, or I don’t know): yes (‘root’ only on the console but su/sudo on a tty)

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

I have been using the getssl ACME client to get/renew certificates because I didn’t want to have two different (incompatible) versions of Python installed. Ubuntu 18.04 LTS has standardized on Python 3.6.5 for everything. I would like to convert my getssl setup to use certbot.

My getssl configuration is working fine and renewing certificates appropriately. I would have expected the above command to show me the cert I have for my domains. I’m trying to learn to do what I want to accomplish myself (and I’m just getting started) but I’m stumped at this particular juncture.

I have a lot of experience with Unix/Linux as a software developer so this isn’t my first rodeo. I’d appreciate any pointers anyone could give me.

Thanks in advance.


Unfortunately, the different clients are using different ways and paths to store their certificates. Clients are not automatically compatible with each other.

The most easy way is just to use certbot to create (a) new certificate(s).


Hi @stevewi,

Certbot has its own database structure for keeping track of certificates that it can renew. Currently, this structure is only created when Certbot itself obtains a certificate, and there’s no feature to import certificates obtained with another tool. So, Certbot doesn’t look for getssl-created certificates, but only for Certbot-created certificates, of which you currently have none.


That’s totally right. Maybe we should work on some import or migration tools in the future (but usually creating new certificates with Certbot is pretty easy).


Am I hearing “feature request” here? :stuck_out_tongue:


Thanks for the quick replies… So, if I’m understanding all your advice correctly, I need to just completely rewrite my getssl front-ends to use certbot (testing using the testing endpoint of course). When it’s all working, I should revoke the getssl cert (using getssl), obtain a new one using certbot and use it going forward.

I have read that I have to generate my own CSR locally using openssl or some such to create/renew certs with certbot I don’t want to use a web server so is this the case? Can I just keep using the same private key and CSR to infinity and beyond to renew a cert?

Thanks again in advance…


That would be a step that would be required anyway if you changed clients, right?

There’s no need to revoke certificates if the private key didn’t get compromised. Or, without the double negative: the only reason to revoke a certificate is when its private key gets compromised.
So assuming the private keys didn’t get compromised, there’s no need to revoke any certificate when changing clients.

That is a step that is required, yes.

That is absolutely not the case. Where did you read that? Even more, using certbot with your own CSR is actually very difficult, because certbot isn’t really build properly for that. Just let certbot generate its own CSR is the usual way to use certbot. And a webserver isn’t necessary, there are more ways to get a challenge validated.

Since version, I think, 0.25 it is possible to keep the same private key for renewals, yes.


You write:

I need to just completely rewrite my getssl front-ends to use certbot

That would be a step that would be required anyway if you changed clients, right?

Well the effort involving getssl was a quick and dirty one because my paid-for GeoTrust cert was expiring. I needed something in place quickly. If I’m going to have to completely overhaul the front-end, I’m going to take some time and do it right (well, as you point out, I was going to have to that anyway) but, while that was happening, I thought I could just quickly patch the existing stuff and then move forward. It sounds like I can just keep using getssl while the overhaul is being designed/developed/tested.

getssl uses the v1 API. There’s a version of getssl that uses the v2 API as well. Should I even bother with the newer getssl?

Lastly, I currently use the same cert for https, smtps and imaps/pop3s. This is the way I was using the GeoTrust cert as well. Should I be doing this? Can you (quickly) outline any pros/cons of doing this?



Maybe we should step back a little bit and ask why? Are you having problems with getssl? Is it lacking features you now need? Because if it’s working for you, it seems odd to go to the work of changing, especially if there are front-end scripts and such that would need to be rewritten.


That has occurred to me as well. My primary reason for wanting to move to certbot is that, IMHO, certbot is better-supported…and it comes from the source so to speak. Plus, I’m retired and this is a learning exercise for me (probably the primary reason).

There are 3 front-end scripts that would need to be rewritten (preceded by line counts):

23 clncert – cleans up the getssl automatic renewal archives
22 mvcert – installs the newly-renewed cert where the web server/mail server know to find it
14 updcert – does the renewal itself

All are written using bash… So you can see, overhauling them would not be a giant effort…and doing so would help me prevent brain atrophy :wink:


If all these services run on the same server there is minimal benefit to separating the certificates. (The minimal benefit is that each certificate are a few bytes smaller. There are also rare situations where one private key on a server is compromised and not another, but most of the time private key compromise is the result of server compromise so all private keys on the server would be compromised at once anyway.)

If all these services run on different servers, you should split the certificates because a compromise of the private key on one would not affect the other, and now it won’t cost you any extra. :slight_smile:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.