Use Arch Linux to generate private key, cert, CSR, CA for hosting service


#1

Hi All.

Is the documentation here current?

I ask because in my up-to-date Arch Linux I have at least two different packages (one official and one in the AUR) to choose from, and I have a feeling (with April news of leaving beta status and renamed client certbot) that the letsencrypt official package was superceded by the certbot-git package in the AUR.

The eff docs above seem to indicate that I should be using letsencrypt, but letsencrypt does not co-exist with AUR package certbot-git, so I installed certbot-git (thinking it was more current). Yet with it, I can’t seem to do something simple like:

certbot certonly --standalone --test-cert -d example.com

For me, this fails with reports that there is a web server already running on port 80. But I’m not trying to generate a cert for this computer that I’m running certbot on; I’m trying to generate the private key, certificate, CSR, and CA for a server running in a hosting service that allows me to upload all four of those items.

Basic questions:

  1. should I use certbot-git from AUR or official package letsencrypt?
  2. how do I go about accomplishing my subject goal (I’ll need to copy/paste the four listed items into my panel in my hosting service web page).

Thank you! :slight_smile:


#2

I don’t know anything about the Arch packaging, but the problem you’re running into with certbot is not certbot-specific (as in: things wouldn’t be different with the letsencrypt package), so the certbot package is probably fine.

Things get a bit tricky here. In order to verify that you own a domain, Let’s Encrypt needs you to solve some kind of challenge. This could be something like serving a file under a well-known, random path - demonstrating that you have control over the website. You’re running certbot with the standalone plugin, which spawns a web server to solve that challenge for you. This is assuming that you’re doing this on a server resolving to the domain(s) you’re trying to get a certificate for.

If you’re doing this on a different host (like your laptop), you can still get a certificate, but you’ll have to find another way to solve the domain ownership challenge. One of the plugins that could help you with that is the manual plugin. WIth this, you can get the client to give you a list of file names (and their content) that you have to create on your actual server (via (S)FTP, the control panel, or whatever you have available). Once you’ve done that, the client will tell Let’s Encrypt that you’re ready to solve the challenge, the CA server will verify that you indeed have done that, and then you’ll get your signed certificate (certbot will show you the path to the certificate, key and chain files once it’s done).

Note that the certificates are only valid for three months, so you’ll have to do this at least four times every year.


#3

Thanks again, @pfg. With the aid of your reply, I think I now better understand what certbot was trying to do during my last attempt at running it (in the command shown in my original post), and your reply makes it clear to me that I should indeed be using the manual plugin only as below:

# certbot certonly --manual --test-cert -d example.com

But at Getting Starged, I read under the “Limits on usage” section:

Let’s Encrypt will issue a limited number of certificates each week. See this
thread for the latest numbers. If you are trying out certbot for the first time, you may
want to use the --test-cert flag, and a domain name that does not receive live
traffic. This will get certificates from our staging server. They won’t be valid in
browsers, but otherwise the process will be the same, so you can test a variety of
configuration options without hitting the rate limit.

So I guess that if I need to demonstrate ownership of any domain that I attempt to make a Let’s Encrypt certificate for (even if I use the --test-cert fllag), then the above guidance “…use the --test-cert flag, and a domain name that does not receive live traffic.” must still be for a domain that I own or control. Is that correct?

If so, then with a limit of “This is limited to 5 certificates per FQDN set per week.”, I think I need to make sure I really understand what I’m doing before attempting to do it for the domain that I’m trying to secure with a Let’s Encrypt certificate.


#4

Correct, you can only get certificates for domains that you own / control.

This is the limit for full certificates ( i.e if you do not use the --test-cert flag).

If you use the --test-cert flag then these restrictive limits do not apply. You can test and make sure you have everything correct using the --test-cert flag and once you are happy that everything is working, remove the flag. You should usually then only need one attempt to get the correct, valid, certificate as you have tested everything already.


#5

Thank you @serverco for the incredibly quick reply! You folks are truly wonderful and I’m very grateful for your help.

However, I regret to say that I have another question on this issue:

I just tried:

# certbot certonly --manual --test-cert -d example.com

not for example.com of course, but for a domain I control, and for output, certbot gave me what seemed to me to be conflicting messages (in the following order):

  1. “Self-verify of challenge failed.”
  2. “Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/example.com/fullchain.pem.”

I’m glad to know that by using the “–test-cert” flag, I did not increase my count regarding usage limits, but why the mixed messages above? I’m pretty sure I correctly followed (and when instructed to do so by certbot and before continuing) certbot’s instructions regarding what content to put at what URL at the domain I control. So why the “Self-verify of challenge failed.” message? Or should I ignore message 1 and trust message 2 and go ahead and remove the --test-cert flag and do the command again for real this time?


#6

I’m not sure why the self-verify failed - maybe the logs in /var/log/letsencrypt have more details. Usually this happens when the device where you’re running the client has no network access to one of the domains - not sure if that’s the case here?

Either way, it’s an optional check, mostly there to help debug issues with verification. You can pretty much ignore it as long as the check from the CA server works (which seems to be the case here, since you got the certificate).


#7

Thanks @pfg. Ok, I’ll ignore message 1.

Two more questions then (for now at least)?:

  1. How do I split out the 4 items my hosting service needs (private key, cert, CSR, and CA) from the single file, etc/letsencrypt/live/example.com/fullchain.pem ? My service asks me to copy/paste (so I assume these are ascii representations) these items into a web form.

I suspect the answer involves using openssl at the command line, and I’m fine with that in general, but I’m afraid I don’t know exactly which invocation of openssl will accomplish my particular goal with the file that I will get from Let’s Encrypt.

  1. Will I need to keep the file that certbot told me to create (with the content it told me to insert there) at the domain in question for the next three months (until I generate a new cert)? Or can I take it down once I get the cert?

#8

There’s a bunch of other files in /etc/letsencrypt/live/example.com/. privkey.pem would be your private key, cert.pem your certificate, chain.pem is probably what it’s asking for with “CA”. I’m a bit confused as to why it would need the CSR as well, but if it really does, you can get it from /etc/letsencrypt/csr - it should be the most recent file in there.

You can delete the file once you got your certificate.


#9

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