Help with creating subdomain certificate

Hello,

I recently installed a certificate following this guide and it worked like a charm.

My domain is: https://wichtv.com

But today, I need to add the certificate to my new subdomain - admin.wichtv.com

After looking online I found some suggestions to run this command:
certbot -a webroot -i nginx --cert-name wichtv.com -d wichtv.com -d www.wichtv.com -d admin.wichtv.com

It then proceeds to ask for me to input the webroot for each domain.

This is the part I don’t quite understand - the folder setup is as follows:

Frontend - /var/www/html/my-folder-name
Admin panel - /var/www/html/my-admin-folder-name

I tried variations of including the folder name and not including the folder name when attempting to input the webroot but each time it comes back with an error:

Failed authorization procedure. admin.wichtv.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://admin.wichtv.com.well-known/acme-challenge/uV7THebqrirFtyww-31XyWDK6vgj9Y_vuupGMBlr7n0: Error getting validation data

Would you please be able to enlighten me as to what webroot I actually enter for both the frontend folder and the admin folder? I’m unsure if I have to use the folder name or just var/www/html/. Because of these repeated attempts, I have hit the limit and will have to try it again later on (hopefully with your wisdom).
There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently:

Lastlly, is the initial error I posted about Failed authorization procedure actually due to entering an incorrect webroot or is it something else?

My web server is (include version): NGINX 1.10.3

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: Digital Ocean

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

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

Hi @Proevilz

Letsencrypt wants a file

https://admin.wichtv.com/.well-known/acme-challenge/uV7THebqrirFtyww-31XyWDK6vgj9Y_vuupGMBlr7n0

but fetches a file

https://admin.wichtv.com.well-known/acme-challenge/uV7THebqrirFtyww-31XyWDK6vgj9Y_vuupGMBlr7n0

So it looks that you have a wrong redirect http -> https with a missing / after the domain name.

PS: You can use the --test-cert - option and certonly. Then you use the testsystem, there are new limits. If the validation works, remove --test-cert and certonly.

This is only a 1-hour-limit.

Hi @JuergenAuer,

Thanks for the reply!

How would I change the url it fetches to include the extra / ?

Would it be a case of adding a slash in the webroot specification?

It's a bug in your nginx configuration itself where a redirection is defined.

Share your nginx configuration file.

1 Like

Hi,

Once again thank you for the continued support and patience.

#
server {

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name wichtv.com www.wichtv.com;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php7.0-cgi alone:
        #       fastcgi_pass 127.0.0.1:9000;
        #       # With php7.0-fpm:
        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        #}
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name wichtv.com www.wichtv.com;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php7.0-cgi alone:
        #       fastcgi_pass 127.0.0.1:9000;
        #       # With php7.0-fpm:
        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}

     
        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/wichtv.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/wichtv.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name example.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

server {
    if ($host = www.wichtv.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = wichtv.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 default_server;
        listen [::]:80 default_server;

        server_name wichtv.com www.wichtv.com;
    return 404; # managed by Certbot



}

That file didn’t mention anything about admin.wichtv.com—is the configuration for admin.wichtv.com possibly defined in a different file?

Hi,

Just for context, I purchased the livestreaming system from https://streamhash.com/

Their technical team has installed it thus far but they say I must add & config SSL by myself as they refuse to do it/help me with it. The nginx file I'm opening is at /etc/nginx/sites-available/default

Despite there being no mention of admin.wichtv.com in the configuration file, the login page loads in the browser. As far as I'm aware, nginx is using the configuration file I specified above hence the letsecrypt stuff being added into and is working for the default domain: https://wichtv.com

The main domain has the same problem:

D:>download http://wichtv.com/.well-known/ -h
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 314
Content-Type: text/html; charset=iso-8859-1
Date: Tue, 21 Aug 2018 17:07:40 GMT
Location: https://wichtv.com.well-known/
Server: Apache/2.4.18 (Ubuntu)

Status: 301 MovedPermanently

Upps - it’s an Apache, not nginx.

So share your Apache configuration.

https://wichtv.com/ sends also Apache-headers.

<VirtualHost *:443>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	ServerName admin.wichtv.com

SSLEngine on
SSLCertificateFile /home/streamnow/ssl/cert.pem
SSLCertificateKeyFile /home/streamnow/ssl/private.pem
SSLCACertificateFile /home/streamnow/ssl/fullchain.pem

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html/streamnow-api-v1.2-luke/public/

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

<VirtualHost *:80>
   ServerName admin.wichtv.com
   Redirect permanent / https://admin.wichtv.com
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Now I see the Redirect permanent / https://admin.wichtv.com - should I add a forward slash to that line only?

I also notice they’re just grabbing the SSL keys from a folder /home/streamnow/SSL/ that they copied into there from the default location letsencrypt uses.

I was under the impression that the site was using nginx exclusively until just now. Apparently they only use nginx for the ‘streaming’ side of things.

Given that I’m now aware it is using Apache to serve files, should I reinstall letsencrypt using the apache plugin?

Sorry, they don’t give me much to go on and they don’t tell me how they set it up.

Yes, at the end of the line.

Thanks.

Considering they’re not using the keys from the /etc/letsencrypt/* folder, will I have to re-copy the keys into their /home/streamnow/ssl/ or won’t the key files actually change in this case of adding a subdomain?

You would probably have to recopy them or else change the files at their locations into symlinks to the Certbot ones.

1 Like

Right, so just to clarify
certbot certonly --test-cert -a webroot -i nginx --cert-name wichtv.com -d wichtv.com -d www.wichtv.com -d admin.wichtv.com

Then I remove both the certonly --test-cert after successful validation? Secondly, given the fact Apache is serving the files, should I switch the plugin from -i nginx to -i apache ? I'm assuming nginx should be fine considering its working already...

It would also be appreciated if you could clarify the webroot path I should use in reference to my original post?

Following on from my previous comment, when I run the command I put above, I get:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You are updating certificate wichtv.com to include new domain(s):
+ admin.wichtv.com

You are also removing previously included domain(s):
(None)

Did you intend to make this change?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(U)pdate cert/(C)ancel: u
Renewing an existing certificate
You've asked to renew/replace a seemingly valid certificate with a test certificate (domains: wichtv.com, www.wichtv.com). We will not do that unless you use the --break-my-certs flag!

So I have to use --break-my-certs like it suggest or not… ?

Well, I was impatience and removed the certonly --test-cert and ran the original command.

This is the new error output

Waiting for verification...

Cleaning up challenges

Failed authorization procedure. admin.wichtv.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://admin.wichtv.com/.well-known/acme-challenge/Z2xktTCS8iRKUeG4wrpyJAODX1nnOOKOgzl2bruVBj0: "&lt;!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"&gt;

&lt;html&gt;&lt;head&gt;

&lt;title&gt;404 Not Found&lt;/title&gt;

&lt;/head&gt;&lt;body&gt;

&lt;h1&gt;Not Found&lt;/h1&gt;

&lt;p"

**IMPORTANT NOTES:**

 - The following errors were reported by the server:

Domain: admin.wichtv.com

Type: unauthorized

Detail: Invalid response from

http://admin.wichtv.com/.well-known/acme-challenge/Z2xktTCS8iRKUeG4wrpyJAODX1nnOOKOgzl2bruVBj0:

"&lt;!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"&gt;

&lt;html&gt;&lt;head&gt;

&lt;title&gt;404 Not Found&lt;/title&gt;

&lt;/head&gt;&lt;body&gt;

&lt;h1&gt;Not Found&lt;/h1&gt;

&lt;p"

To fix these errors, please make sure that your domain name was

entered correctly and the DNS A/AAAA record(s) for that domain

contain(s) the right IP address.

I set the webroot to their respective folders for the frontend folder and the public/frontend folder for the wichtv.com www.wichtv.com & admin.wichtv.com.

I have noticed that there are actually symlinks for each of the folders inside /var/www/html by running ls -la

streamnow-angular-v1.2-luke -> /home/streamnow/streamnow-angular-v1.2-luke/ streamnow-api-v1.2-luke -> /home/streamnow/streamnow-api-v1.2-luke/

Secondly, I only notice one .well-known folder and thats in the frontend folder streamnow-angular-v1.2-luke

Update: I created a .well-known/text.txt inside streamnow-api-v1.2-luke/ (admin) and noticed it still returns a 404 for the .well-known directory. I need to figure out why this happens.

Yep, I don't understand your configuration.

Testing

download http://admin.wichtv.com/.well-known/acme-challenge/1234 -h
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 346
Content-Type: text/html; charset=iso-8859-1
Date: Tue, 21 Aug 2018 19:24:45 GMT
Location: https://admin.wichtv.com/.well-known/acme-challenge/1234
Server: Apache/2.4.18 (Ubuntu)

Status: 301 MovedPermanently

it's redirected to https. But your protocol doesn't do the same:

Detail: Invalid response from
http://admin.wichtv.com/.well-known/acme-challenge/Z2xktTCS8iRKUeG4wrpyJAODX1nnOOKOgzl2bruVBj0

Your older protocol had that redirect to https without "/".

Does this streamnow redirects all these directories?

But you have created certificates (2018-08-17):

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:www.wichtv.com&lu=cert_search

Which command was used?

Ok so I figured out the 404 it was because apache had an extra folder on the webroot /public (Laravel) so I removed it and I was able to access the .well-known folder.

I then used to the command I originally posted and it created the certificate successfully, but I had an error with nginx

Input the webroot for admin.wichtv.com: (Enter 'c' to cancel): /var/www/html/streamnow-api-v1.2-luke
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
nginx: [error] invalid PID number "" in "/run/nginx.pid"
Rolling back to previous server configuration...
nginx: [error] invalid PID number "" in "/run/nginx.pid"
Encountered exception during recovery: 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 507, in deploy_certificate
    self.installer.restart()
  File "/usr/lib/python3/dist-packages/certbot_nginx/configurator.py", line 858, in restart
    nginx_restart(self.conf('ctl'), self.nginx_conf)
  File "/usr/lib/python3/dist-packages/certbot_nginx/configurator.py", line 1118, in nginx_restart
    "nginx restart failed:\n%s\n%s" % (out.read(), err.read()))
certbot.errors.MisconfigurationError: nginx restart failed:
b''
b''

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/error_handler.py", line 108, in _call_registered
    self.funcs[-1]()
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 607, in _rollback_and_restart
    self.installer.restart()
  File "/usr/lib/python3/dist-packages/certbot_nginx/configurator.py", line 858, in restart
    nginx_restart(self.conf('ctl'), self.nginx_conf)
  File "/usr/lib/python3/dist-packages/certbot_nginx/configurator.py", line 1118, in nginx_restart
    "nginx restart failed:\n%s\n%s" % (out.read(), err.read()))
certbot.errors.MisconfigurationError: nginx restart failed:
b''
b''
nginx restart failed:
b''
b''

IMPORTANT NOTES:
 - An error occurred and we failed to restore your config and restart
   your server. Please post to
   https://community.letsencrypt.org/c/server-config with details
   about your configuration and this error you received.
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/wichtv.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/wichtv.com/privkey.pem
   Your cert will expire on 2018-11-19. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"

I forgot I stopped the nginx service earlier on today. I am unable to start it due to port conflicts with Apache. (I am not sure how the Streamhash.com technical team had both running simultaneously) so thats what I suspect the error is.

Once nginx has been started up, would I just run the same command again so it can access the config file successfully?

Now you have the correct certificate with three names:

https://transparencyreport.google.com/https/certificates/%2BqHkd1exBDzGDF4dae0wSEoByP0%2FLyolX5vaaFAZc8s%3D

admin.wichtv.com
wichtv.com
www.wichtv.com

So check your configuration with

Certbot certificates

to find the complete path + filenames of this certificate. And use these in your apache configuration.

PS: http://wichtv.com/.well-known/ has also the wrong redirect to https://wichtv.com.well-known/