SSL problem; certificate points to another website on same server

trellis
5

acme file. Could you make sure the server has this file:
/etc/nginx/acme-challenge-location.conf

acme include directive. Then ensure /etc/nginx/sites-available/website.nl.conf has three instances of
include acme-challenge-location.conf;
Here’s an abbreviated version of where these includes should appear
(there is vertical scroll on code block below):

server {
  <snip>
  ssl_certificate         /etc/nginx/ssl/letsencrypt/website.nl-53859fd-bundled.cert;
  ssl_certificate_key     /etc/nginx/ssl/letsencrypt/website.nl.key;

  include acme-challenge-location.conf;

  include includes.d/website.nl/*.conf;

  # Prevent PHP scripts from being executed inside the uploads folder.
    <snip>
  }
}

# Redirect to https
server {
  listen 80;
  <snip>

  include acme-challenge-location.conf;

  location / {
  <snip>
}

# Redirect some domains
server {
  listen 443 ssl http2;
  <snip>
  ssl_certificate         /etc/nginx/ssl/letsencrypt/website.nl-53859fd-bundled.cert;
  ssl_certificate_key     /etc/nginx/ssl/letsencrypt/website.nl.key;

  include acme-challenge-location.conf;

  location / {
  <snip>
}

Reload Nginx. There’s a chance that all your Nginx confs were correct but with the false starts, an Nginx reload was never triggered (a tiny bit related to issues in roots/trellis#783). That’s great you checked sudo nginx -t :+1: and let’s be sure you’ve done a sudo service nginx reload which could/should only help and not hurt.

I suspect that you were able to load www.website.nl/.well-known/acme-challenge/ping.txt only after it redirected to https and that the http version of anything at www.website.nl/.well-known/acme-challenge was actually giving the 404. This 404 could be due to Nginx not having been reloaded, despite the confs being correct.

Registrar’s domain parking page. Another possibility is that for a little while I noticed that your website.nl loaded your registrar’s domain parking page (at an IPv6 for your registrar; not the IPv4 in your DNS). I think that several hours ago I even got that parking page for the www.website.nl domain. I began wondering if your registrar – and its Name Servers in effect for your domains – could be exhibiting some strange behavior. However, this has all stopped now for me: website.nl forwards to www.website.nl and ultimately redirects to https :+1:. Oh wait, scratch that. In Chrome incognito after clearing hsts (chrome://net-internals/#hsts) I’m back to seeing the registrar domain parking page for both www.website.nl and website.nl

I find that rather surprising and I’d recommend moving your Name Servers to Digital Ocean.

Edit. I suspect the DNS entries visible to you with your registrar’s Name Servers only show an A record pointing your IPv4 and that your DO server is only configured to serve IPv4. However, it seems your Name Servers are nonetheless serving an IPv6 and it corresponds to your registrar, not your DO server.

The output of the original post shows that indeed 'addressesResolved' included your IPv4 and some other IPv6 (registrar). Then, the failed LE validation must have occurred due to 'addressUsed': u'2a01:7c8:eb:0:149:210:209:163' – that is your registrar’s IPv6, not your web server’s IPv4.

You could remove any AAAA (IPv6) records you find in your DNS. If there aren’t any, it seems puzzling (euphemism) that your registrar’s NS are returning an AAAA you haven’t set:

# (real domain replaced)
$ nslookup -query=AAAA www.website.nl                                                                                                                                                                                    ...
www.website.nl	canonical name = website.nl.
website.nl	has AAAA address 2a01:7c8:eb::149:210:209:163
3 Likes