How will LE replace an existing certificate without causing any interruption? Will LE modify httpd.conf (on Apache) automatically, or will this need to be done manually? Is so, how?
2 Likes
Don’t see why httpd.conf would need to be modified. Just replace the cert file with the new cert. Then restart Apache, or is there a command to refresh the cert without restarting the web server?
Thank you @NOYB ! Sure thing – if the names and location of LE’s files correspond to those in the config file, all is good. I trust this will be documented once the automated process is in place. It would be great, however, to know already at this point what exactly happens when LE replaces current certificates so that sites being whitelisted these days will be prepared.
Right now the Apache and Nginx integration does not replace existing cert files on disk. It would be possible to do what @NOYB suggests, but then automated renewal wouldn’t happen.
With the existing integration the references to the cert in the web server configuration should be replaced (but the existing certs would still exist in their original locations on disk). I can try to do this and describe in more detail what changes happen in the configuration files if people are interested, but maybe someone here can refine the question a little bit – what behaviors do you expect or what behaviors would you like to see from the client?
For Apache as far as we know it’s necessary to reload the server configuration in order to take advantage of new certs (and the client will attempt to do this when the certs are obtained and some time after they’re renewed). If Apache makes some other option available, we could try to take advantage of it. We’re trying to make the installation as convenient as possible in the common case so that most users wouldn’t need to edit server configuration files manually if they don’t want to.
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!
1 Like
@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;
1 Like
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.
2 Likes
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.
3 Likes
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.
1 Like
Yeah for non standard Nginx and Apache setups as long as I can script it via shell scripts I’d be happy 
1 Like
I’ll file a GitHub issue about this question, and you’re welcome to discuss the matter there.
2 Likes
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 ?
1 Like
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?
1 Like
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.
3 Likes
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 
1 Like
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