LE replacing a current certificate


Maybe have letsencrypt client/tools to be able remember and get users to specify the location of their ssl key/crt files in a config file or something for apache or nginx. Then have the tool auto backup and move those and place the new letsencrypt certs in same location with exact same file names and then restart apache or nginx.

That’s probably what I’d have to do for my Centmin Mod LEMP web stack as Nginx vhost auto generates the SSL vhost for self-signed certs first in path at /usr/local/nginx/conf/ssl/mydomain.com/ where paid SSL would be placed too i.e. https://community.centminmod.com/posts/17649/.


Hi @eva2000, I don’t think we’ll do that by default because of the risk of potential confusion between the LE certs and the existing certs. Currently our client software always creates a new PEM file for every new certificate so that the sysadmin can more easily remember or recognize which files have which contents. We use symbolic links for versioning of the Let’s Encrypt certs on disk so that server configuration files won’t have to modified every time.

I think our current approach is working pretty well in this respect, but we could use a lot more help with testing and feedback to make sure that it works with people’s existing setups and configuration files!


@schoen yeah that makes sense

so basically for folks with their own custom server setups apache, litespeed, nginx we can use those created symlinks ?

i.e. so for nginx ?

ssl_certificate      /letsencrypt/symlink/to/domain.com.crt;
ssl_certificate_key  /letsencrypt/symlink/to/domain.com.key;


That’s right, but right now we don’t have a mode that creates the symlinks (and enrolls the keys for autorenewal) without also installing into some web server. So one question is whether we ought to have a mode like that, that creates the symlink structure within /etc/letsencrypt instead of just saving the PEM files into the current working directory.

In the current implementation, it’s one or the other: if you have server integration (a full-fledged “installer” plugin), you get the autorenewed certificate lineage with symlinks under /etc/letsencrypt. If, on the other hand, you use manual or standalone modes, I think you’d currently get PEM files in the current directory from which you ran the client, and they wouldn’t be autorenewed at all.


I’d suggest that if LE is going to stand pat on the max 90 day lifetime that the manual mode include an option for creating the symlinks. Everything that can be done to make manual renewals less burdensome will help. With symlinks pointing at the new certs would it be conceivable to write a shell script that renews the cert and then restarts the associated service to load the new cert? If so that would be about the next best thing to a client supported service/app. But I still really don’t like the idea of forcing such a short lifetime.

Of course if all that is feasible then probably also feasible for a script to move the files around and restart the service too.

Never mind me. Just think online (out load). Also sometimes referred to as talking to oneself or day dreaming.


Right now the notion of “manual” includes at least four different things.

  • The client doesn’t need to run as root.
  • The client doesn’t interactively perform the DV validation for the user.
  • The client doesn’t install the cert into any server software.
  • The client doesn’t install the cert into /etc/letsencrypt or create symlinks or a renewal configuration file that would result in automated renewal. (Consequently, no automated renewal can happen, and manual renewal can’t be triggered from within the client environment either.)

In principle, these things could be further separated, if it wouldn’t confuse users.


If the tasks could be broken out enough (perhaps into command line options) such that a shell script could accomplish everything to automate for non supported services like mail servers etc. it seems like that would sure help.


Yeah for non standard Nginx and Apache setups as long as I can script it via shell scripts I’d be happy :slight_smile:


I’ll file a GitHub issue about this question, and you’re welcome to discuss the matter there.


Actually letsencrypt client manual mode does create the symlinks in /etc/letsencrypt as well just tried it on my non-standard Nginx config for CentOS 6.7 https://community.centminmod.com/threads/letsencrypt-ssl-certificate-on-centmin-mod-nginx-http-2.4250/

ls -lAhrt /etc/letsencrypt/live/le1.http2ssl.xyz/
total 0
lrwxrwxrwx 1 root root 43 Aug 29 07:52 privkey.pem -> ../../archive/le1.http2ssl.xyz/privkey1.pem
lrwxrwxrwx 1 root root 45 Aug 29 07:52 fullchain.pem -> ../../archive/le1.http2ssl.xyz/fullchain1.pem
lrwxrwxrwx 1 root root 41 Aug 29 07:52 chain.pem -> ../../archive/le1.http2ssl.xyz/chain1.pem
lrwxrwxrwx 1 root root 40 Aug 29 07:52 cert.pem -> ../../archive/le1.http2ssl.xyz/cert1.pem

so all i need to do is get my Nginx SSL vhost generator to switch to

# letsencrypt
ssl_certificate /etc/letsencrypt/live/le1.http2ssl.xyz/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/le1.http2ssl.xyz/privkey.pem;

But this is for initial SSL cert issue not renewals so not sure if it’s the same ? If symlinks are made in manual mode, then folks could script their vhost setups accordingly or wouldn’t need to make subsequent changes for renewals if they already set their paths to the symlinked files ?


So, when LE goes public, renewals won’t happen manually? If they won’t, then how would IIS be supported, since nobody but the user can change IIS’s configuration?


We’ll have to ask the IIS port developers how they think they could handle renewal. It probably will be rather different from the Unix version.


@eva2000, I didn’t realize that manual mode would create the symlinks already – that’s different from what I expected. In that case I’m not sure what renewals will look like, but you could try rerunning the client with the same names and key and see if it makes a new …/…/archive/le1.http2ssl.xyz/cert2.pem, key2.pem, chain2.pem, and fullchain2.pem.

But please try that next week, because I have to add a patch this week that deals with recognizing that rerunning the client with the same names should be treated as a renewal, something that the current version of the client doesn’t understand yet.


okay will run and see once you have that patch in place next week.

For commit notifications, I know github commits has an rss feed but not sure if discourse can use that rss feed in anyway ? On my forums I setup a dedicated forum which pulls my github repo’s commits in as a new thread https://community.centminmod.com/forums/centmin-mod-github-commits.41/ that gives folks another avenue for replies, feedback on commits other than github commit itself. Just an idea as not all Letsencrypt users will be on Github.


I think when people start doing all the development of a project via something like GitHub it makes it a bit hidden from view. I use GitHub myself, but really only for hosting repositories, I wouldn’t consider using GitHub as a development platform.

At my previous job, I’d set up mailing lists for each project with a devel and commits list. All development took place on the devel lists and Git commits were also sent to the commits lists. There was also Bugzilla, Mediawiki and IRC.

I’m sure some of this must sound familiar :wink:


yeah i use github for hosting my code, but never really gotten into using mailing lists - I grew up on forums since 2000 and past 15yrs have been working in the forum software industry so hard to shake off heh


I myself use only IIS 10.0 on Windows 10, so I am asking for myself, how can I get a certificate and then renew it manually? (I can help you if you need something from IIS.)


@Jason, I don’t know the current status of the IIS port. Hopefully we can get an update about it soon.

An inconvenient solution is to use the standalone mode in the Unix client on a Unix machine and save the private key, certificate, and chain as files, which you could then copy onto your Windows machine and import. I realize this is not ideal for the long run; although the certificates are free of charge, this would no longer necessarily be simpler and faster than getting certs from other CAs.

Split "Issuance and Renwal" into Policy and Technical categories

This is incorrect. Right now, all certificates/keys are enrolled in renewal unless only a CSR is provided (The client never has access to the key in this case).



Thanks for the correction, @jdkasten.