I'd like to learn - Grateful for any help


#1

Please fill out the fields below so we can help you better.

My domain is:

I ran this command:

It produced this output:

My operating system is (include version):CentOS 7 x64

My web server is (include version):nginx

My hosting provider, if applicable, is:Vultr

I can login to a root shell on my machine (yes or no, or I don’t know):Yes

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

Hi everyone,

I’d like to be able to install an SSL certificate on my server, which is self.managed.

I’m able to login to a root shell with a program called MobaXTerm, but that’s pretty much it.

I’d be grateful to you if you’d be kind enough to tell me what types of programming language I need to learn in order to install an SSL cerificate or do other types of changes to my web server.

This is the only way for me to be able to so this, and I’m willing to take the time and effort to learn.

Thank you for your help.


#2

None, the official client of Let’s Encrypt is called certbot, which is a complete and independent application, and you can find instuctions on the following site: https://certbot.eff.org

If you run into problems or need any help, you can always ask here! (But please be as detailed as possible if you do, so we can help you better and quicker!)


#3

Hi Osiris,

Thank you for your kind reply.

I will be more specific. The domain (“domain 1”) on which I needed to install the SSL certificate was used to install a third-party service. This was done automatically by a script that was provided by the service itself. I asked their support staff to help me with the installation of the LetsEncrypt SSL certificate too, and they agreed to do it for me, even if this was outside the scope of their support.

However, both now and in the future I will need to modify the existing SSL certificate, which I’m going to have to do on my own. Notably, I need to add other subdomains to the main SSL certificate. These subdomains are CNAMEs of a second domain (“domain 2”), and they point to the URL of “domain 1”.

I have consulted this guide https://certbot.eff.org/docs/using.html and gave it a try, but it didn’t work.

I found the installed certificate by typing

certbot certificates

and then I ran this command:

certbot certonly --cert-name [name of the existing SSL certificate] -d www.domain1.com,domain1.com,example.domain2.com,www.example.domain2.com

The certificate had been already installed only on “www.domain1.com” and “domain1.com

I believe I didn’t do any damage, but I was unable to add the CNAMEs under the existing certificate.

This is the error I got:

Failed authorization procedure. example.domain2.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://example.domain2.com/.well-known/acme-challenge/etctetc: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>", www.example.domain2.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for www.example.domain2.com

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: example.domain2.com
   Type:   unauthorized
   Detail: Invalid response from
   http://example.domain2.com/.well-known/acme-challenge/etcetc:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</h1></center>
   <hr><center>"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.
 - The following errors were reported by the server:

   Domain: www.example.domain2.com
   Type:   connection
   Detail: DNS problem: NXDOMAIN looking up A for
   www.example.domain2.com

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

I’d be grateful to you if you could help understand if the initial command itself was incorrect, or if I might have made a mistake subsequently - for example, when I was asked to select the webroot.


#4

The output you gave indicates two errors: (1) the webroot for example.domain2.com is incorrect, and (2) there are no DNS records for www.example.domain2.com.

To correct (1), you’d run the command as:

certbot certonly --cert-name (existing cert name) -w /path/to/domain1 -d www.domain1.com -d domain1.com -w /path/to/domain2 -d example.domain2.com -d www.example.domain2.com

Each -d flag specifies a single FQDN, and the -w flag gives the webroot path for every FQDN that follows it, until the next -w flag.

To correct (2), you need to make sure that there are valid DNS records for www.example.domain2.com. A record for *.domain2.com won’t do this.


#5

certbot certonly --cert-name (existing cert name) -w /path/to/domain1 -d www.domain1.com -d domain1.com -w /path/to/domain2 -d example.domain2.com -d www.example.domain2.com

Hi danb35,

Thank you for your help.

I ran the command you gave me, but I’m doing something wrong with the certificate path.

I got this message:

/etc/letsencrypt/live/www.example.domain2.com does not exist or is not a directory

I believe I was able to find the path of the existing certificate by running certbot certificates, which gave me this:

Found the following certs:
  Certificate Name: www.domain1.com
    Domains: www.domain1.com domain1.com
    Expiry Date: 2017-07-11 13:16:00+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/www.domain1.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/www.domain1.com/privkey.pem

According to my reasoning, the certificate path I had to enter after -w for domain1 is this: /etc/letsencrypt/live/www.domain1.com

Is that correct?

Regarding domain2, I just made up and typed another path with the same format, like this:

/etc/letsencrypt/live/www.example.domain2.com

Therefore, this is what I typed:

certbot certonly --cert-name www.domain1.com -w /etc/letsencrypt/live/www.domain1.com -d www.domain1.com -d domain1.com -w /etc/letsencrypt/live/www.example.domain2.com -d www.example.domain2.com -d example.domain2.com

What I’m thinking is that maybe the path for domain2 was not accepted because I had to create it first. If so, how should I do it?

Also, I would like to add that the CNAMEs should be added within the existing certificate. Given that, is it still correct to create another path for domain2?


#6

No, the path for the -w flags is the webroot path. That is, the path to the webserver’s root directory. It has nothing to do with where the certs are stored.


#7

Hi,

I think did it right this time. I found the webroot path by typing grep -i 'DocumentRoot' /etc/httpd/conf/httpd.conf

This is the certbot command I typed:

certbot certonly --cert-name www.domain1.com -w /var/www/html -d www.domain1.com -d domain1.com -w /var/www/html -d www.example.domain2.com -d example.domain2.com

Does it look right this time? Unfortunately it didn’t work for some reason - I got the same error message I got the first time.

Failed authorization procedure. www.example.domain2.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.example.domain2.com/.well-known/acme-challenge/_LP4d3w58a35H9GJmSwTbmRj9etcetc: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>", example.domain2.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://example.domain2.com/.well-known/acme-challenge/KdoNoqVbR9Elf44WIjboetcetc: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.example.domain2.com
   Type:   unauthorized
   Detail: Invalid response from
   http://www.example.domain2.com/.well-known/acme-challenge/_LP4d3w58a35H9GJmSwTbmRj9Aetcetc:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</h1></center>
   <hr><center>"

   Domain: example.domain2.com
   Type:   unauthorized
   Detail: Invalid response from
   http://example.domain2.com/.well-known/acme-challenge/KdoNoqVbR9Elf44WIjboetcetc:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</h1></center>
   <hr><center>"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

I don’t understand why it keeps asking about the A record. The subdomain of domain2 was CNAMEd to domain1 - isn’t this enough to connect the 2 domains?

One more thing. After typing the crtbot command I was asked a question:

How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Place files in webroot directory (webroot)
2: Spin up a temporary webserver (standalone)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

I selected the webroot directory. Could this have caused the error?


#8

Is it really true that the webroot path is the same for both sites? This would suggest that the content of the two sites is the same as well!

The question about the authentication method is just because you didn’t specify --webroot as part of your command line. If you add --webroot, you won’t be asked about this.


#9

Hi schoen,

Thank you for your suggestions.

Is it really true that the webroot path is the same for both sites? This would suggest that the content of the two sites is the same as well!

Regarding the webroot path, example.domain2.com is just a subdomain of domain2 which I have CNAMEd to domain1. This is how I see it - The server has to think that domain1 and domain2 have a different content (or think nothing at all about this) but it needs to think that the subdomain of domain2 has the same content of domain1.

All I want to do is include the subdomain of the other site within the already existing certificate.

I have no idea what to do at this point. I can’t understand what the problem is. Any inputs would be greatly appreciated.

Thank you everyone for your time and you help.


#10

If you put a file test1.txt in /var/www/html, can you see it in a web browser under both domains?

(if so, then:) If you put a file test2.txt in /var/www/html/.well-known/acme-challenge/test2.txt, can you see it in a web browser under both domains?


#11

I managed to create the test file like you said

[root@vultr ~]# cd /var/www/html
[root@vultr html]# touch test1.txt
[root@vultr html]# ls -F
test1.txt

However, if I type this is the address bar: domain1.com/test1.txt I get the “404 not found” page. For the record, the same happens if I visit the homepage of domain1. I am using this domain to host - so to speak - a tracking tool which I can access from domain1/admin/etc.php

I did not install this myself. All I did was run from shell a script/program which was written by the creator of this tool.

I also did a DNS check on domain1 just in case, and found no errors except these:

Name Servers are on the Same Subnet
xxx.xx.xx 

	SOA Serial Number Format is Invalid
ns1.vultr.com reported Serial 1478xxxxxx : Suggested serial format year was 1478 which is before 1970. 	 

	SOA Expire Value out of recommended range
ns1.vultr.com reported Expire 604xxx : Expire is recommended to be between 1209600 and 2419200.

I hope this might explain why I’m unable to register a CNAME subdomain with the existing SSL certificate.


#12

Thanks for trying this experiment.

So, that means that /var/www/html is not currently the correct webroot directory for domain1.com. That, in turn, is (at least one reason) why Certbot was unable to obtain the certificate. Could you take another look at your nginx configuration files (probably within /etc/nginx) to try to understand more about what the correct webroot directory might be?


#13

If I entered the wrong path that might indeed be the reason!

Unfortunately, I’m unable to take it further with my current skills. The command I entered to find the webroot path was

grep -i 'DocumentRoot' /etc/httpd/conf/httpd.conf

I found it on a website and it was supposed to work for nginx CentOS.

I’d appreciate it if you could suggest an alternative way to find the webroot path. I hope I’m not asking too much.

EDIT

I was able to find the correct webroot path, which was /usr/share/nginx/html

The test file was visible after I created it from that directory. Therefore, I ran the same certbot command I had tried before and this time it worked!

However, the ssl isn’t working yet on https://example.domain2.com

I did an ssl check for both domain1.com and example.domain2.com and they are still displaying the same expiry date as yesterday.

My question is: is it possible that SSL info takes a while to propagate to ssl checkers and the actual websites, just like DNS changes?


#14

Hi,

As I guess you learned, there are different virtual hosts representing different sites that are hosted on the same server, and each may have its own configuration file and its own document root.

The reason “certonly” is called “certonly” is that it means “only obtain the certificate, don’t install it”. (This contrasts with the behavior of some Certbot plugins of also attempting to install the certificate after obtaining it.) Thus your certificate now exists somewhere in /etc/letsencrypt/live but your nginx hasn’t been configured to use it.

There is no propagation delay with certificates; as soon as they’re configured on a server, they’re immediately visible. But you have to edit your nginx configuration files for your virtual hosts to mention that you want nginx to speak HTTPS (like Apache, nginx continues to use the obsolete term “ssl”) and that you want it to use the certificate and private key that were just generated.

I don’t happen to know how to do this offhand but there should be many tutorials and references online explaining how to install a new certificate in nginx. The “It worked!” message that Certbot printed when you succeeded should have mentioned the exact path to the file containing the certificate and chain. (In the same location there is also a privkey.pem, containing the corresponding private key.)


#15

Hi,

I was finally able to do it, somehow. I tried to do the most intuitive thing and - incredibly - it worked. Seriously, I just can’t believe it… Beginner’s luck, I guess :laughing:

Thanks everyone for your help!


#16

Next you can check on whether automated renewal is set up! :slight_smile:


#17

I believe there’s something wrong.

Inside the file /etc/letsencrypt/renewal/www.domain1.com.conf I see the following:

# renew_before_expiry = 30 days
version = 0.12.0
archive_dir = /etc/letsencrypt/archive/www.domain1.com
cert = /etc/letsencrypt/live/www.domain1.com/cert.pem
privkey = /etc/letsencrypt/live/www.domain1.com/privkey.pem
chain = /etc/letsencrypt/live/www.domain1.com/chain.pem
fullchain = /etc/letsencrypt/live/www.domain1.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = 1f3b798ea185ab14fa925c875f190090
webroot_path = /usr/share/nginx/html, /usr/share/nginx/html
[[webroot_map]]
www.example.domain2.com = /usr/share/nginx/html
example.domain2.com = /usr/share/nginx/html
domain1.com = /usr/share/nginx/html
www.domain1.com = /usr/share/nginx/html

This file is making a reference to cert.pem, privkey.pem, fullchain.pem

However, inside the directory where these are located, the pem files are duplicated

[root@vultr ~]# ls -al //etc/letsencrypt/archive/www.domain1.com
total 40
drwxr-xr-x 2 root root 4096 Apr 14 14:30 .
drwx------ 3 root root 4096 Apr 12 14:15 ..
-rw-r--r-- 1 root root 1834 Apr 12 14:15 cert1.pem
-rw-r--r-- 1 root root 1919 Apr 14 14:30 cert2.pem
-rw-r--r-- 1 root root 1647 Apr 12 14:15 chain1.pem
-rw-r--r-- 1 root root 1647 Apr 14 14:30 chain2.pem
-rw-r--r-- 1 root root 3481 Apr 12 14:15 fullchain1.pem
-rw-r--r-- 1 root root 3566 Apr 14 14:30 fullchain2.pem
-rw-r--r-- 1 root root 1704 Apr 12 14:15 privkey1.pem
-rw-r--r-- 1 root root 1704 Apr 14 14:30 privkey2.pem

April 12 is when the original certificate was created, whereas April 14 is when I added the subdomains.

I’m wondering if this is normal behaviour or if I accidentally duplicated them.

Anyways, as of now the paths of the .pem files I found in the conf file /etc/letsencrypt/renewal/www.domain1.com.conf do not match the current file paths.

Assuming that the pem files have been “duplicated” because I updated the existing certificate and there’s nothing wrong with it, would this be the correct way to modify the conf file?

# renew_before_expiry = 30 days
version = 0.12.0
archive_dir = /etc/letsencrypt/archive/www.domain1.com
cert = /etc/letsencrypt/live/www.domain1.com/cert1.pem
cert = /etc/letsencrypt/live/www.domain1.com/cert2.pem
privkey = /etc/letsencrypt/live/www.domain1.com/privkey1.pem
privkey = /etc/letsencrypt/live/www.domain1.com/privkey2.pem
chain = /etc/letsencrypt/live/www.domain1.com/chain1.pem
chain = /etc/letsencrypt/live/www.domain1.com/chain2.pem
fullchain = /etc/letsencrypt/live/www.domain1.com/fullchain1.pem
fullchain = /etc/letsencrypt/live/www.domain1.com/fullchain2.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = 1f3b798ea185ab14fa925c875f190090
webroot_path = /usr/share/nginx/html, /usr/share/nginx/html
[[webroot_map]]
www.example.domain2.com = /usr/share/nginx/html
example.domain2.com = /usr/share/nginx/html
domain1.com = /usr/share/nginx/html
www.domain1.com = /usr/share/nginx/html

Thanks again for your help.


#18

The renewal configuration file is refering to the /live/ directory for most of the part! Only the first line is refering to /archive/. And you’re checking this /archive/ directory, while you should check/use /live/! In the /archive/ directory, every old certificate or key or whatever is kept there. New ones are added with the next following number. The /live/ directory symbolically links to the most recent file in /archive/. So the only thing you’d need to remember is always refer to the files in /live/ because otherwise you’d get into trouble when you renew the certificate. The symbolic links in /live/ will be updated to the most recent ones, so if you only refer to the files in /archive/, you’d end up with a broken site or service, because those (the references to files in /archive/ aren’t updated. Therefore, always use /live/ in configuration files!


#19

Hi,

Thank you for pointing that out!

At the moment, the renewal configuration file is this:

# renew_before_expiry = 30 days
version = 0.12.0
archive_dir = /etc/letsencrypt/archive/www.domain1.com
cert = /etc/letsencrypt/live/www.domain1.com/cert.pem
privkey = /etc/letsencrypt/live/www.domain1.com/privkey.pem
chain = /etc/letsencrypt/live/www.domain1.com/chain.pem
fullchain = /etc/letsencrypt/live/www.domain1.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = 1f3b798ea185ab14fa925c875f190090
webroot_path = /usr/share/nginx/html, /usr/share/nginx/html
[[webroot_map]]
www.example.domain2.com = /usr/share/nginx/html
example.domain2.com = /usr/share/nginx/html
domain1.com = /usr/share/nginx/html
www.domain1.com = /usr/share/nginx/html

Just to make sure, does this mean that automated renewal is correctly set up for all the domains I included within the certificate? The domains are: domain1.com, www.domain1.com, example.domain2.com, www.example.domain2.com


#20

The renewal configuration is a reflection of the options you’ve provided certbot when you requested a certificate in the first place. If that worked, the renewal configuration should be correct. The only reason to doubt the renewal configuration for correctness is if you’ve changed anything to your webserver configuration yourself.

I can’t confirm if that renewal configuration file is correct, as I don’t know if the webroots from the [[webroot_map]] are correctly refering to the root directives of your nginx configuration files. However, if the issuing of the cert with those webroots worked in the first place, it should be correct.