A few processes not clear to me yet

I’ve generated a couple certificates so far on CentOS, and it went quite well. The letsencrypt-all didn’t actually do everything for me, since I got an error about a missing ‘installer’ of some sort. But the certs did get created. I just needed to manually copy the certs and adjust the apache ssl.conf to use the certs. Not a problem. My questions:

  1. It appears this whole process needs to be run ON the same web server for which the certificate is to be used. Is this true? If so, how can multiple domains be specified on the command line? Or is the assumption that all those domains point back to the same web server?

  2. There seems to be a tremendous amount of packages being installed during the setup. Why so much intensive python code? Is all of this necessary in my setup, where the ‘installer’ never actually completely worked and I ended up manually moving all the certs anyway?

  3. the --debug threw me for a loop. When I first saw this, I simply expected more verbose output. Instead, by throwing the --debug, it actually performed many more installation steps and allowed my installation to succeed where it failed without the --debug. Can someone explain this?

  4. What exactly is meant by ‘standalone’ ? What are some of the other possibilities?

  5. How can letsEncrypt be used with a hosting provider, such as iPage, where I don’t actually have a shell or root access to the server? All I really need is the cert itself, but I couldn’t find the right combination of options to allow me to run the letsencrypt-auto without actually being on the webserver itself.

Thanks!

  1. Yes, the letsencrypt client is most appropriately (i.e., most easily) run on the server for which the certificate is being generated. Multiple hosts/domains can be specified, but they ordinarily would all point to the same server.

  2. No idea.

  3. I don’t know what all the --debug option does, but one thing I know it does is allow the client to run with Python 2.6, which is what’s installed in CentOS 6.

  4. https://letsencrypt.readthedocs.org/en/latest/using.html#plugins

  5. The best answer would probably be for the hosting provider to directly support LetsEncrypt. But failing that, using the “manual” plugin should do what you need. The client will give you a specific string that needs to be placed at a specific location on your site, to verify that you control the host.

1 Like
  1. No, there’s also manual mode, where the client will ask you to put the challenge into the designated file in the right spot in the webroot of your host. This can be a server on the other side of the world, as long as you have control over this server/domain (via SSH/SFTP of the sorts). If you specify multiple domains, I recon it will ask you as many times for a challenge. But I’ve never tried that actually.
  2. and 4. See @danb35, 3 and 5 see answer @ 2. :stuck_out_tongue:
1 Like

Thanks for the reply!
I’ve seen the plugins help, but it’s really vague. It still doesn’t really explain very well what any of them do. For example, ‘standalone’. What exactly IS a standalone server? Or ‘webroot’: “Obtains a cert by writing to the webroot directory of an already running webserver” How can writing to a directory in the document root ‘obtain a cert’ ? Or is this what you refer to in #5 where I place a string in a directory of the web server?

Thanks!

The Let’s Encrypt client needs ‘proof’ that you really own/control the specified domain(s) (you can enter multiple domains by enter multiple -d switches on the command line). It depends on the “plugin” how the Let’s Encrypt client handles the so called challenge.

As the plugin introduction says, there are “authenticators” and “installers”. Installers will handle all the work for you: the challenge (authentication) and installation of the certificate in your webserver. This would be the apache and nginx plugins.

The standalone plugin (envoked with letsencrypt-auto certonly --standalone -d domain.tld -d www.domain.tld -d someother.domain.tld) will start its own webserver, hence “standalone”. This isn’t very practical if there’s already a webserver running. You’ll have to stop that one, run Let’s Encrypt, start the webserver again… Unpractical if you’d ask me.

The webroot plugin is almost the same as the standalone plugin, but makes use of the already existing webserver. Instead of stopping the existing one and starting it’s own, it places the “challenge” we talked about before into your sites webroot. The only thing is: you’ll have to specify where that webroot is. Not very hard, you’ll probably know that :wink: Ofcourse, you’ll have to run the Let’s Encrypt client from the server itself or have direct (NFS/Samba) access to the webroot somehow. The command would be: letsencrypt-auto certonly --webroot --webroot-path /var/www/vhosts/domain.tld/htdocs/ -d domain.tld -d www.domain.tld -d someother.domain.tld (ofcourse, the location of the webroot is distribution specific…) As multiple domains don’t always have the same webroot, you can specify multiple webroot-paths: letsencrypt-auto certonly --webroot -w /var/www/vhosts/domain1/htdocs/ -d domain1.tld -w /var/www/vhosts/domain1/htdocs/ -d domain2.tld for example. (-w is a shortcut for --webroot-path).

With --manual it’ll ask you to put the challenge-token into a specified file into a specific directory of the webroot yourself. That way you could generate certificates from the other side of the world and place the challenge token by SSH of FTP or something. :smile:

2 Likes

As for 2: If you do not like this you may have a look at acme-tiny.

1 Like

Great info! That’s what I was hoping to learn. So, the mini webserver and all which makes that work is probably a significant part of the code. I noticed some virtualization happening, which was curious. But now it makes more sense.
Thanks for taking the time to explain in more detail. Hopefully others will find it useful as well!

Yes, I saw this too. Good stuff! I might have to write a wrapper to do all that as well. It does look nice and simple though.
Thanks!