Error in TLS Certificate Provisioning

#1

Hi,

A couple of weeks ago I started getting the following email every day warning me about the TLS certificate expiration. Can anyone please help me with this issue?

Provisioning TLS certificates for box.serhat.cc.
error: box.serhat.cc:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Performing the following challenges:
http-01 challenge for box.serhat.cc
Using the webroot path /home/user-data/ssl/lets_encrypt/webroot for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. box.serhat.cc (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: During secondary validation: 2a03:b0c0:0:1010::14a:e001: Fetching http://box.serhat.cc/.well-known/acme-challenge/acYy3_yc5HyY8NmxVTfm5ArOq_PGhH2TenRrhTo4j5w: Timeout during connect (likely firewall problem)
IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: box.serhat.cc
    Type: connection
    Detail: During secondary validation: 2a03:b0c0:0:1010::14a:e001:
    Fetching
    http://box.serhat.cc/.well-known/acme-challenge/acYy3_yc5HyY8NmxVTfm5ArOq_PGhH2TenRrhTo4j5w:
    Timeout during connect (likely firewall problem)

    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. 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.

#2

There is something wrong with your IPv6 address.

Do you have any errors in the dashboard status checks page?

#3

I have had tried provisioning the certificate manually from the admin panel and it gave errors. I just tried again and somehow it worked.
But while trying to solve the problem, I added a few custom DNS records like CAA and AAAA. Because the email was telling me things like “box.serhat.cc does not have a CAA record.”. So I added that. Do you think I can safely remove the ones I added recently? I thought MIAB was managing all the required DNS records.

#4

Does the status checks on the dashboard report any errors? I know I sound like a broken record, but you appear to have some strangeness related to DNS and should be reported on the status checks page.

The reason that custom DNS records make the errors no longer be reported is because MiaB stops checking records that have a custom DNS entry. However, it does not mean there isn’t some problem with the record.

#5

I just see the following error for the domains:

MTA-STS policy is missing: STSFetchResult.NONE

I also have this warning:

This domain’s DNSSEC DS record is not set. The DS record is optional. The DS record activates DNSSEC. See below for instructions.

#6

Please post the output of:

sudo ufw status
#8

Here it is:

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
22/tcp                     LIMIT       Anywhere
53                         ALLOW       Anywhere
25/tcp                     ALLOW       Anywhere
587/tcp                    ALLOW       Anywhere
993/tcp                    ALLOW       Anywhere
995/tcp                    ALLOW       Anywhere
4190/tcp                   ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
465/tcp                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
22/tcp (v6)                LIMIT       Anywhere (v6)
53 (v6)                    ALLOW       Anywhere (v6)
25/tcp (v6)                ALLOW       Anywhere (v6)
587/tcp (v6)               ALLOW       Anywhere (v6)
993/tcp (v6)               ALLOW       Anywhere (v6)
995/tcp (v6)               ALLOW       Anywhere (v6)
4190/tcp (v6)              ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
443/tcp (v6)               ALLOW       Anywhere (v6)
465/tcp (v6)               ALLOW       Anywhere (v6)
#9

The WHOIS record for your domain includes Digital Ocean NS hostnames. Is there some reason you configured these? You can see it at GWhois (you have to expand DNS at the bottom of the left column).

#10

Yes, I just added them in case the mail server had a problem. Do you think I should remove them?

#11

Yes, you should remove the DO NS records before doing anything else.

If you want a failover DNS server, you need to properly configure one. One of the other moderators, @alento, has a tutorial at Setting up Secondary DNS for Mail-in-a-Box - AnyDomain LLC which uses puck.nether.net, and another option is dns.he.net though not in the tutorial. However, you should do this after your server is performing as expected.

Even though your firewall is configured to support IPv6, the DNS server does not respond to requests for aaaa records on the NS hostnames except for your box subdomain. I recommend clearing the Custom DNS records.

I also cannot get any response on port 80 or 443 from your IPv6 address. Does DO have an external firewall that is blocking requests to the IPv6 address? If not, you might try running sudo mailinabox.

#12

Oh, and you need to add the DNSSEC information to the DS records of the domain. These are added in your GoDaddy interface, as those records are managed by the registrar, not the VPS provider.

#13

Many thanks! Let me digest these and get back with updates. Cheers!

#14

@sguven Please do not add DNSSEC until after you get the other issues sorted out.

As @openletter mentions you want to determine why your server is not accessible via IPv6 first, and then work from there.

1 Like
#15

Thank you both!

Apparently I had to update the /etc/netplan/50-cloud-init.yaml file to include the IPv6 information. For future reference it is described in https://docs.digitalocean.com/products/networking/ipv6/how-to/enable/#on-existing-droplets. With this update, the MTA-STS policy is missing: STSFetchResult.NONE error was resolved.

As for the DNSSEC setup, my initial research suggests that my domain’s TDL type does not support the DNSSEC, unfortunately. Going forward I will ensure that this is the case and if so I am going to migrate the MIAB to a different domain.

Thanks again for your quick turnarounds!

#16

Your IPv6 address is now accessible on the expected ports.

While not critical, your nameserver will respond from the IPv6 address, but it will not serve any IPv6 addresses (e.g., dig -6 aaaa example.com does not receive a response). Somehow MiaB isn’t seeing the IPv6 address. If you desire to use IPv6, I suspect you will need to run sudo mailinabox, but I’m not totally sure on that.