Set up ddns and now browser reports website is insecure

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: safeandtacticalfirearmstraining.com

I ran this command:

It produced this output:

My web server is (include version): Apache

The operating system my web server runs on is (include version): OpenSuse 15.4

My hosting provider, if applicable, is: GoDaddy

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

I recently set up DDNS service No-IP. GoDaddy now forwards users to stft.ddns.net, which shows in the address bar. My website appears but with a warning that it is not secure. I have run certbot to renew both URL's and received the following output:


certbot -v
Saving debug log to /var/log/letsencrypt/letsencrypt.log
ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: safeandtacticalfirearmstraining.com
2: www.safeandtacticalfirearmstraining.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Requesting a certificate for safeandtacticalfirearmstraining.com
Performing the following challenges:
http-01 challenge for safeandtacticalfirearmstraining.com
Waiting for verification...
Challenge failed for domain safeandtacticalfirearmstraining.com
http-01 challenge for safeandtacticalfirearmstraining.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Domain: safeandtacticalfirearmstraining.com
  Type:   unauthorized
  Detail: 3.33.251.168: Invalid response from http://safeandtacticalfirearmstraining.com/.well-known/acme-challenge/TjGOqg0OFaZFZzMSTGtmBYcRrAXwDcL3pZnsBQg-_Ok: 403

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

I also connected thru openSSL and received the following:

penssl s_client -connect safeandtacticalfirearmstraining.com:443 MMSServer safeandtacticalfirearmstraining.com
s_client: Use -help for summary.
geno@safeandtacticalfirearmstraining:~> openssl s_client -connect safeandtacticalfirearmstraining.com:443
CONNECTED(00000003)
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 CN = safeandtacticalfirearmstraining.com
verify return:1
---
Certificate chain
 0 s:CN = safeandtacticalfirearmstraining.com
   i:C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
 1 s:C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
   i:C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGqzCCBZOgAwIBAgIIYIB/5A5fIowwDQYJKoZIhvcNAQELBQAwgbQxCzAJBgNV
BAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMRow
GAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UECxMkaHR0cDovL2NlcnRz
LmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQDEypHbyBEYWRkeSBTZWN1
cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwHhcNMjUwMzA0MTkxMjE2WhcN
MjYwMzA0MTkxMjE2WjAuMSwwKgYDVQQDEyNzYWZlYW5kdGFjdGljYWxmaXJlYXJt
c3RyYWluaW5nLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKP4
UvzgKWpwTPIGQ3TSQZ/+5DU+ZkLcypKnlkYUYUs9yRYRhUQGX169WV8l9e2DR/Ha
Vs2yiWeQvWR2Vi13ADnph1fpu5T+IxKN38QJcgv/SxQ/xFaG5fKVnF03wDNpHdtR
4rhBjG2f35Pb4eBPx/udTw3HS+VNh1rAw3VKH0aYq1B5CxhNS/Cxj3hS2szU4d1k
u3FzGmWUrS19zxYNdU7kQWaywHoa2Lsd+kVnKjybbWyIrKCnQtolHlmL22bRMD9A
cc6tGJ4TNRHHXpEVwMfuXSU3Og8+IwqyjBeZ/gsdkeGjutZK0aFeXZ0qU6pGyjLS
i4a4m0+xQ30H8CyE6t0CAwEAAaOCA0QwggNAMAwGA1UdEwEB/wQCMAAwHQYDVR0l
BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB/wQEAwIFoDA5BgNVHR8E
MjAwMC6gLKAqhihodHRwOi8vY3JsLmdvZGFkZHkuY29tL2dkaWcyczEtNDA5NTAu
Y3JsMF0GA1UdIARWMFQwSAYLYIZIAYb9bQEHFwEwOTA3BggrBgEFBQcCARYraHR0
cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5LzAIBgZngQwB
AgEwdgYIKwYBBQUHAQEEajBoMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5nb2Rh
ZGR5LmNvbS8wQAYIKwYBBQUHMAKGNGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRk
eS5jb20vcmVwb3NpdG9yeS9nZGlnMi5jcnQwHwYDVR0jBBgwFoAUQMK9J47MNIMw
ojPX+2yz8LQsgM4wLgYDVR0RBCcwJYIjc2FmZWFuZHRhY3RpY2FsZmlyZWFybXN0
cmFpbmluZy5jb20wHQYDVR0OBBYEFIR3xF7j2FFpNcm+zS5Iauv5EdclMIIBfQYK
KwYBBAHWeQIEAgSCAW0EggFpAWcAdgAOV5S8866pPjMbLJkHs/eQ35vCPXEyJd0h
qSWsYcVOIQAAAZVikrflAAAEAwBHMEUCIQD0WYLO5JCw4+ILlJO1LE28M1wGpz+3
1dm/RzBHDAsEpQIgLAHETn8UMIocOOnGmgoEVMTSnzzoXs0KHC46Q9LGBNsAdQBk
EcRspBLsp4kcogIuALyrTygH1B41J6vq/tUDyX3N8AAAAZVikrjVAAAEAwBGMEQC
IDcXLhbH4+QRmLRF9YggyE8+al8idkFU0XDGC8MF7HYoAiBLkq36+tsren/sxgAw
i59N+DvpkzBmbIc+aWZBLkApUAB2AMs49xWJfIShRF9bwd37yW7ymlnNRwppBYWw
yxTDFFjnAAABlWKSuYoAAAQDAEcwRQIgF4PXGrMIL8KsjRhedHb/1aIa2Rzh2iNr
WKMjTTd8aPoCIQDYUoFCYgdMGzWckWnTZpVuC9fKOqZdXAUlfu8j8nSdrTANBgkq
hkiG9w0BAQsFAAOCAQEAgrXibZscOIvDBL9NYqfIt/UUy/fsUVtShHFQH0jDOQxd
sLqOE9QiaY1T5Sr+mtX1RomtVkd3QrxOjFypLtOByBnGDP9ANgGa4C7VfawnFnPN
5/1oOsllr1BKRrXWES48hN7Yr1jjrQ79RKj0fKeZsEoknWsPcxxh9EouzHSnBa4b
hUDZApMcGmfoDKKLTiKfcHqQk0njXdpE5n43dFHO4UdQKVUukJ+OYrL3ktWDj3KC
WHO5JsiHGr8fhp4hSpgBI3GS+wh/LwCTGue6u4QNnzDIaeGnPlemdieH2omLoHcT
c8IlIw+UyT28ZB0NsqfTz45ZMMjOxo1CJIjwfhw7+w==
-----END CERTIFICATE-----
subject=CN = safeandtacticalfirearmstraining.com

issuer=C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3492 bytes and written 409 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
closed

How can I further troubleshoot this problem?

Thanks,

Gene

2

Your new GoDaddy service is a redirect service from your prior (long) name to the new one. And, that service takes care of the certificate for those names (safeandtacticalfirearmstraining.com).

It redirects to your stft.ddns.net name using HTTPS so that server must have a cert with that name in it. It looks like you run an Apache server there. But, right now only HTTP requests to that work which is why browsers say the site is not "safe".

On your Apache server, you might try running

sudo certbot certonly --apache --dry-run -d stft.ddns.net

If that works run it without certonly and without --dry-run. If it fails let us know the error message

2 Likes
3

I ran

 #: certbot certonly --apache --dry-run -d stft.ddns.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.
Simulating a certificate request for stft.ddns.net
The dry run was successful.

Then I ran:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.
Simulating a certificate request for stft.ddns.net
The dry run was successful.

Whatever the effect, No-IP didn't like it and it is no longer forwarding users to my web server. Both GoDaddy and the server appear to be working properly.

What do the error messages tell you?

4

The second paste didn't post properly, can't find an edit function so here it is again:

#: certbot --apache -d stft.ddns.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.
Requesting a certificate for stft.ddns.net

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/stft.ddns.net/fullchain.pem
Key is saved at: /etc/letsencrypt/live/stft.ddns.net/privkey.pem
This certificate expires on 2025-07-30.
These files will be updated when the certificate renews.

Deploying certificate

We were unable to find a vhost with a ServerName or Address of stft.ddns.net.
Which virtual host would you like to choose?

1: STFT-vhost.conf | Multiple Names | | Enabled
2: STFT-vhost.conf | Multiple Names | HTTPS | Enabled

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Successfully deployed certificate for stft.ddns.net to /etc/apache2/vhosts.d/STFT-vhost.conf
Failed redirect for stft.ddns.net
Unable to set the redirect enhancement for stft.ddns.net.

NEXT STEPS:

  • The certificate was saved, but could not be installed (installer: apache). After fixing the error shown below, try installing it again by running:
    certbot install --cert-name stft.ddns.net
  • The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See User Guide — Certbot 4.1.0.dev0 documentation for instructions.

Unable to find corresponding HTTP vhost; Unable to create one as intended addresses conflict; Current configuration does not support automated redirection
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

5

Looks like you have a faulty Apache config. Let's start by showing us output of this

sudo apachectl -t -D DUMP_VHOSTS

You may need httpd or apache2ctl instead of apachectl. I don't recall which one OpenSuse Apache uses

1 Like
6 
# apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80                   www.safeandtacticalfirearmstraining.com (/etc/apache2/vhosts.d/STFT-vhost.conf:17)
*:443                  www.safeandtacticalfirearmstraining.com (/etc/apache2/vhosts.d/STFT-vhost.conf:58)
7

Please show contents of that file.

Isn't this server supposed to be handling requests to your stft.ddns.net domain? Because the ServerName is your long domain name which is now handled elsewhere.

2 Likes
8

This configuration isn't making sense from my perspective. It would be worth pausing to determine what the desired outcome is here. If the DDNS hostname is just meant to allow the long hostname to reach a server at a dynamic IP, a CNAME would be better than a redirect, and no certificate would needed for the DDNS hostname, since the site would still be using the original long hostname.

3 Likes
9

Wouldn't that require the existing GoDaddy redirect service to redirect HTTP(S) from the apex to the www subdomain? Then add the CNAME from the www subdomain to the ddns name.

Otherwise they can't CNAME from the apex to the ddns name.

There may be other DNS and/or DDNS services that are more elegant. But, CNAME from apex names isn't normally allowed.

2 Likes
10

You are correct that a CNAME at the apex is not valid, however there are ways around this limitation, such as Cloudflare CNAME Flattening, although other providers have similar features. My point is that it seems undesirable to start th visit at a proper domain, only to be redirected to some hostname in an entirely unrelated free DDNS provider subdomain. If I were a site visitor, I would find that behavior to be sketchy and off-putting.

2 Likes
11

I would be wary too. They have a fairly long history of getting LE certs. Last we saw they were self-hosted so perhaps their ISP now charge for a static IP.

Depending on their audience a redirect to a ddns domain may not be a problem. But you make a good point that they should evaluate what they want to achieve and then design a solution. It's very possible they chose the wrong solution for their problem.

3 Likes
12

I am hosting my server from home in a small rural town. The ISP will not give me a static IP unless I upgrade to a business-class account which is considerably more expensive and well beyond my needs.

Previously, when my website failed which might be weeks or months down the timeline, would check the public IP, log into GoDaddy, and manually configure the domain to the new IP. Problem is, I never knew when the ISP would change my dynamic IP. While away on trips I would worry about it - many trips are hunting in areas where no cell coverage is available.

So my solution was to get a DDNS service. I'm pretty new with it, so I may well have configured it poorly. The configurations were suggested by NO-IP support, and the rep seemed very impatient and rushed. I did the best I knew, but I am still learning and would appreciate your input on a better way. A little theory along with your suggestions would be very helpful to grow my brain.

STFT-vhost.conf listing:

# Template for a VirtualHost with SSL
# Note: to use the template, rename it to /etc/apache2/vhost.d/yourvhost.conf.
# Files must have the .conf suffix to be loaded.
#
# See /usr/share/doc/packages/apache2/README.QUICKSTART for further hints
# about virtual hosts.
#
# This is the Apache server configuration file providing SSL support.
# It contains the configuration directives to instruct the server how to
# serve pages over an https connection. For detailing information about these 
# directives see http://httpd.apache.org/docs/2.4/mod/mod_ssl.html
#
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.  

<VirtualHost _default_:80>

        #  General setup for the virtual host
        DocumentRoot "/srv/www/htdocs/STFT"
        ServerName www.safeandtacticalfirearmstraining.com
        ServerAlias safeandtacticalfirearmstraining.com
        ServerAdmin geno11x11@gmail.com
        ErrorLog /var/log/apache2/error_log
        TransferLog /var/log/apache2/access_log

        #   SSL Engine Switch:
        #   Enable/Disable SSL for this virtual host.
        SSLEngine off

        #   OCSP Stapling:
        #   Enable/Disable OCSP for this virtual host.
        SSLUseStapling  off

        #   You can use per vhost certificates if SNI is supported.

        #   Per-Server Logging:
        #   The home of a custom SSL log file. Use this when you want a
        #   compact non-error SSL logfile on a virtual host basis.
        CustomLog /var/log/apache2/ssl_request_log   ssl_combined

RewriteEngine on
RewriteCond %{SERVER_NAME} =safeandtacticalfirearmstraining.com [OR]
RewriteCond %{SERVER_NAME} =www.safeandtacticalfirearmstraining.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>


<IfDefine SSL>
<IfDefine !NOSSL>

##
## SSL Virtual Host Context
##
#Listen 80
#Listen 443

<VirtualHost _default_:443>

        #  General setup for the virtual host
        DocumentRoot "/srv/www/htdocs/STFT"
        ServerName www.safeandtacticalfirearmstraining.com
        ServerAlias safeandtacticalfirearmstraining.com
        ServerAdmin geno11x11@gmail.com
        ErrorLog /var/log/apache2/error_log
        TransferLog /var/log/apache2/access_log

        #   SSL Engine Switch:
        #   Enable/Disable SSL for this virtual host.
        SSLEngine on

        #   OCSP Stapling:
        #   Enable/Disable OCSP for this virtual host.
        #   SSLUseStapling  on

        #   You can use per vhost certificates if SNI is supported.

        #   Per-Server Logging:
        #   The home of a custom SSL log file. Use this when you want a
        #   compact non-error SSL logfile on a virtual host basis.
        CustomLog /var/log/apache2/ssl_request_log ssl_combined

        Include /etc/letsencrypt/options-ssl-apache.conf
        ServerAlias stft.ddns.net
	SSLCertificateFile /etc/letsencrypt/live/stft.ddns.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/stft.ddns.net/privkey.pem
</VirtualHost>

</IfDefine>
</IfDefine>
1 Like
13

Thanks for the added background @Geno11x11

We can help you get your no-ip solution working fairly easily I think. But, the question is will you like the result?

As you noted in your first post, when someone starts with your long .com domain name they end up seeing your new short ddns.net domain in the address bar. There is nothing technically wrong with that. Just some people may find it unprofessional.

Is seeing the stft.ddns.net name acceptable to you?

1 Like
14

Absolutely! I can inform users about the URL.

15

Okay. We'll want to make some changes to your Apache config. But, it should work as it is. Just by luck, not by design :slight_smile: So, we'll fix that.

But, first we need to fix your port 443. HTTPS requests to your stft.ddns.net domain currently timeout. Probably because you have a firewall blocking port 443. Or perhaps your home router doesn't send port 443 requests to your Apache server. Do you do port or NAT forwarding and is it setup for port 443?

HTTP requests on port 80 connect fine. Which is how you could get the cert. But HTTPS (port 443) do not.

curl -I -m7 https://stft.ddns.net
curl: (28) Connection timed out after 7001 milliseconds

curl -I -m7 http://stft.ddns.net
HTTP/1.1 200 OK
Server: Apache
1 Like
16

What if you didn't have to? While I would encourage you to not host your website on your residential circuit if we were having that discussion, there are better ways to deal with your situation than employing HTTP forwarding to a No-IP DDNS hostname.

You can use Cloudflare for your DNS and update your actual hostname easily with their API. If you use their proxy, it will protect your residential IP from being exposed to visitors. A Cloudflare Tunnel offers similar benefits without the need to update your IP via the API since the tunnel connects from your server to Cloudflare and the inbound traffic can traverse the tunnel.

If you want to explore those options, the Cloudflare Community is a good resource. I'll put this tangent to rest so you get on with obtaining your certificate.

3 Likes
17 
But, first we need to fix your port 443. HTTPS requests to your stft.ddns.net domain currently timeout. Probably because you have a firewall blocking port 443. Or perhaps your home router doesn't send port 443 requests to your Apache server. Do you do port or NAT forwarding and is it setup for port 443?

I recently upgraded my router to obtain embedded OpenVPN functionality. I created a list of old router settings for the new but apparently missed port 443 forwarding. I corrected that issue and now everything is working properly on my website, in particular, no browser security warnings.

Returning to the topic of configuration, you suggested using CNAME instead of forwarding and mentioned benefits related to that. In the interest of learning the ropes, I would like to know more about this; perhaps you could direct me to good online resources that won't be too far over my head. I will also look into Cloudflare.

Thanks for your input, which directed me to my router mistake and the solution to my immediate problem.

2 Likes
18

Excellent. We should still improve / fix your Apache config.

In your STFT-vhost.conf there are two VirtualHosts with these two names:

  ServerName www.safeandtacticalfirearmstraining.com
  ServerAlias safeandtacticalfirearmstraining.com

You can leave those two names here even though this Apache server is not handling them anymore. They are being handled by that GoDaddy redirect service. But, in case you setup a "fancier" way you may need these again.

But, you should add a 3rd name to the list. This is the domain your Apache is handling. Add this additional ServerAlias in both VirtualHosts.

  ServerName www.safeandtacticalfirearmstraining.com
  ServerAlias safeandtacticalfirearmstraining.com
  ServerAlias stft.ddns.net

Similarly, adjust your rewrites from this:

RewriteCond %{SERVER_NAME} =safeandtacticalfirearmstraining.com [OR]
RewriteCond %{SERVER_NAME} =www.safeandtacticalfirearmstraining.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

to this:

RewriteCond %{SERVER_NAME} =stft.ddns.net [OR]
RewriteCond %{SERVER_NAME} =safeandtacticalfirearmstraining.com [OR]
RewriteCond %{SERVER_NAME} =www.safeandtacticalfirearmstraining.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

My personal preference is to also remove these 4 lines although this is optional. They can make certain problems harder to find if you mis-configure your system. Your system only works right with SSL properly configured so no reason to have these.

<IfDefine SSL>
<IfDefine !NOSSL>

</IfDefine>
</IfDefine>
1 Like
19

I didn't suggest that. I'm happy enough to have sorted out the problems you arrived with. I'll leave that for other volunteers to comment on if they wish :slight_smile:

The details of that involve server design and DNS configuration which isn't the main priority here.

2 Likes