Help setting up Apache + DuckDNS and other domain name

For a while now I have just been using Nextcloud successfully with a Let’s Encrypt certificate as well as a DuckDNS subdomain name, however now I want to use my own subdomain with Let’s Encrypt. So the idea is that I have mydomain.duckdns.org, and a purchased domain name of mydomain.com, with a cname of cloud.mydomain.com pointing to mydomain.duckdns.org.

Oddly, I have this working with another Wordpress web server I have, but it’s using nginx. I tried to expand my current certificate using this command:

certbot certonly --webroot -w /var/www/html -d mydomain.duckdns.org -d cloud.mydomain.com

When I run that command certbot asks if I want to expand my certificate to include my new domain name with my current certificate and everything works without error, here’s the output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/mydomain.duckdns.org.conf)

It contains these names: mydomain.duckdns.org

You requested these names for the new certificate: mydomain.duckdns.org,
cloud.mydomain.com.

Do you want to expand and replace this existing certificate with the new
certificate?

(E)xpand/©ancel: E
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for mydomain.duckdns.org
http-01 challenge for cloud.mydomain.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification…
Cleaning up challenges

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/mydomain.duckdns.org-0001/fullchain.pem.
    Your cert will expire on 2017-08-08. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    "certbot renew"
  • If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Additionally, I did a restart of Apache and also tried just restarting the server afterwards. When I visit cloud.mydomain.com I get the error:

cloud.mydomain.com uses an invalid security certificate. The certificate is only valid for mydomain.duckdns.org Error code: SSL_ERROR_BAD_CERT_DOMAIN

I am using the PPA provided on certbot.eff.org on an Ubuntu 16.04 server. I have also cleared all the caches on my web browsers. Strangely, Safari on my iPhone doesn’t complain, but Brave on my iPhone does. My goal is to just be able to access cloud.mydomain.com and not see mydomain.duckdns.org when using the server. Is this a certificate error? I have 2 ServerName lines in my apache configs

It sounds you have multiple certificates for that domain, certbot expanded one, but Apache is using a different one. You might have to adjust your Apache configuration to point to the correct expanded certificate.

I’m not sure why Safari and Brave would behave differently … unless maybe one of them doesn’t support SNI? Try visiting https://www.ssllabs.com/ssltest/viewMyClient.html in both browsers and see what it says about “Server Name Indication (SNI)”. If one of them doesn’t support it, you’ll have to make sure your default SSL VirtualHost is pointing to the correct certificate - as opposed to the VirtualHost that has the correct ServerName.

If you need more detailed help, you’ll probably have to post the relevant parts of your Apache configuration.

When you say multiple certs, are you referring to where it says “Your certificate and chain have been saved at
/etc/letsencrypt/live/mydomain.duckdns.org-0001/fullchain.pem.”? In that case, I have had that issue handled. In the beginning of setting this up (many months ago) I had a strange hiccup renewing a cert and it wound up creating that -0001 directory separate, so I started using that. Certbot created the expanded cert in the -0001 directory and Apache is pointing to that one as well.

As for Safari vs. Brave, they both run on the same browser base, so they should both have identical results with that test (on iOS). I did the test though and they both support SNI. I will put my Apache configs in a separate reply

<VirtualHost *:80>
# 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 mywebsite.duckdns.org
ServerName mywebsite.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html


    Redirect permanent / https://mywebsite.duckdns.org/

    # 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

#RewriteEngine on
#RewriteCond %{SERVER_NAME} =mywebsite.duckdns.org
#RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

Alias /nextcloud “/var/www/html/”

<Directory /var/www/html>
Options +FollowSymlinks
AllowOverride All

Dav off

SetEnv HOME /var/www/html
SetEnv HTTP_HOME /var/www/html

RewriteEngine on
RewriteCond %{SERVER_NAME} =www.mywebsite.duckdns.org [OR]
RewriteCond %{SERVER_NAME} =mywebsite.duckdns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

# 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 www.mywebsite.duckdns.org ServerName mywebsite.com
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    <IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
    </IfModule>


    # 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

Alias /nextcloud “/var/www/html/”

<Directory /var/www/html>
Options +FollowSymlinks
AllowOverride All

Dav off

SetEnv HOME /var/www/html
SetEnv HTTP_HOME /var/www/html

SSLCertificateFile /etc/letsencrypt/live/www.mywebsite.duckdns.org-0001/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.mywebsite.duckdns.org-0001/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

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

Okay so I see at least two things happening here.

The first is that putting two ServerName directives in the same VirtualHost doesn’t do what you think: the second one simply overrides the first. If you want the VirtualHost to match both names (or more than two), you should put one in ServerName and all the others in ServerAlias.

The second thing is that you seem to have some inconsistency in whether you refer to your DuckDNS domain as mywebsite.duckdns.org or www.mywebsite.duckdns.org. In particular, your HTTP VirtualHost seems to use mywebsite.duckdns.org while the HTTPS one uses www.mywebsite.duckdns.org, and also you are referencing the Let’s Encrypt certificates in /etc/letsencrypt/live/www.mywebsite.duckdns.org-0001/ while Certbot’s output seems to indicate that it stored the expanded certificate in /etc/letsencrypt/live/mydomain.duckdns.org-0001.

That may have been an error in my find & replace :sweat_smile:

I double checked my configs for consistency and they are consistent, I think I just failed at the paste. Everything is in fact going to /etc/letsencrypt/live/www.mywebsite.duckdns.org-0001/ and being read from there in my config files.

I then went and tried changing www.mydomain.com to ServerAlias and cloud.mydomain.com to ServerName and vise versa, and also tried Expanding the certificate that way with no luck, it just keeps saying that the domain is only for mydomain.duckdns.org even after completion

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