Home server with private IP address

I am setting up a NextCloud server in a FreeBSD jail. The name/IP is not accessible to the Internet. My phone won't connect to a non-https site so I would like to get a valid cert for the site. I admin Linux boxes so I am very comfortable with the CLI and run my own DNS servers (email and web sites as well).

When I try to get a cert I can't find any generic info about generating a certbot request unless I turn over my DNS to someone else with an API. I edit the DNS text files myself. I can put TXT records in by hand but there is no API. The domain is known to the world but my home network is not. The server can get to the Internet but the Internet cannot access my server.

How do I get a cert generated? I release I will likely have to do this manually a few times a year.

Thanks,
Carl

2 Likes

See the Certbot documentation page about getting certs and choosing a (authentication) plugin: User Guide — Certbot 1.30.0 documentation

You're looking for the plugin which can do the dns-01 challenge with manual input.

That said, you should consider running acme-dns which only requires a one-time CNAME resource record in your DNS zone. While there is a public and free acme-dns server available online, it's better to run your own instance for obvious security reasons.

You can use acme-dns-certbot-joohoi or acme-dns-client for integration of acme-dns with Certbot.

Also, I'm moving your thread to the #help section as it's not really a question about issuance policy but a question on how to get a cert issued.

5 Likes

To clarify the above response: You need to perform a DNS-01 challenge that resolves to nameservers available on the public internet. There is an option in Certbot to handle DNS in manually, but automating it with acme-dns will be the easiest, especially when it comes time for renewal.

In the recommended solution, you delegate the _acme-challenge dns record to a specific domain, and run an acme-dns server on the public internet. The acme-dns server only needs to run when you are obtaining a certificate. If you run acme-dns on the same machine that gets the certs, it can be turned on/off with the pre/post hooks. If you run it on a different machine, you can schedule it to only be up for a few minutes.

4 Likes

Hi @cws, and welcome to the LE community forum :slight_smile:

In order to obtain a cert from a globally trusted CA, the NextCloud server will need an FQDN that can be resolved via the global DNS system.
In order to obtain an LE cert from a system that can't be reached by the Internet, you will have to use DNS-01 authentication.
In order to automate the use of DNS authentication, you will need, either:

  • a DSP that allows zone updates via API and an ACME client with a plugin that works with it
    OR
  • use a CNAME from your zone to one that can be automated and used to satisfy the DNS challenge
    As stated above, this choice can be served by several DNS methods [maybe even from your site]

In all cases:
In order to automate this certificate process, you will need:

  • a real Internet domain name [FQDN]
  • a DNS zone that can be updated automatically [via API]
  • access to the Internet [can't be done completely offline]

That said, before committing to this solution, you can also achieve the DNS-01 authentication manually [without API use].
[to ensure the resulting LE cert is indeed the answer to your problem]

4 Likes

Thank you for the pointer and your time to read this. I do support for other things and realize the imposition on your time.

Most of the other answers simply said I should use a DNS with on API when I stated in the original post that I am quite comfortable with editing files and don't want to switch DNS servers. BTW - I use 'vi' for changing my DNS (web and mail) and have been doing things by hand since 1992. Using Unix since 1982. However I am beginning to think of doing it or just giving up on LetsEncrypt

I followed the directions several times and each one failed at the validation. The last time I waited for the TTL to pass before I tried to validate my domain. I have included the times, 'dig' and 'whois' results to show that it should have passed. I looked through the logfile (also attached) and it just says that it failed with a traceback. The site intodns.com has no issue with my DNS.

dns-validation.txt (5.4 KB)

root@nextcloud:/usr/local/www/nextcloud/apps # certbot certonly -v --manual --preferred-challenges dns -d '*.faultline.com'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Requesting a certificate for *.faultline.com
Performing the following challenges:
dns-01 challenge for faultline.com


Please deploy a DNS TXT record under the name:

_acme-challenge.faultline.com.

with the following value:

Y8-QfJXqlE2_VG_xlhoco55e60JneJRqZ9ujGEfXbIU

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: Dig (DNS lookup).
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.


Press Enter to Continue
Waiting for verification...
Challenge failed for domain faultline.com
dns-01 challenge for faultline.com

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: faultline.com
Type: unauthorized
Detail: During secondary validation: Incorrect TXT record "E1T480cPTm56nzx2mlDIQNa-mC7xYlqRzbqyBumO7Os" found at _acme-challenge.faultline.com

Hint: The Certificate Authority failed to verify the manually created DNS TXT records. Ensure that you created these in the correct location, or try waiting longer for DNS propagation on the next attempt.

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.

letsencrypt.log.txt (19.8 KB)

Thanks,
Carl

1 Like

I do not find a DNS TXT Record with _acme-challenge in it here:DNS Lookup - Check DNS Records
Let's Debug passes here Let's Debug and here Let's Debug

Nor with: My BAD! :slightly_frowning_face:, It is here!
_acme-challenge.faultline.com text = "Y8-QfJXqlE2_VG_xlhoco55e60JneJRqZ9ujGEfXbIU"

$ nslookup
> server ns2.faultline.com.
Default server: ns2.faultline.com.
Address: 69.164.209.149#53
> faultline.com
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

Name:   faultline.com
Address: 69.164.209.149
> set q=soa
> faultline.com
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

faultline.com
        origin = ns2.faultline.com
        mail addr = root.ns2.faultline.com
        serial = 202209182
        refresh = 7200
        retry = 3600
        expire = 864000
        minimum = 7200
> set q=txt
> faultline.com
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

faultline.com   text = "v=spf1 a mx ip4:69.164.209.149 -all"
> _acme-challenge.faultline.com.
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

_acme-challenge.faultline.com   text = "Y8-QfJXqlE2_VG_xlhoco55e60JneJRqZ9ujGEfXbIU"
>

1 Like

I don't know why this would be but I get different responses from your different NS

dig TXT _acme-challenge.faultline.com @ns1.faultline.com +short
"Y8-QfJXqlE2_VG_xlhoco55e60JneJRqZ9ujGEfXbIU"

dig TXT _acme-challenge.faultline.com @ns2.faultline.com +short
"Y8-QfJXqlE2_VG_xlhoco55e60JneJRqZ9ujGEfXbIU"

dig TXT _acme-challenge.faultline.com @ns3.faultline.com +short
"E1T480cPTm56nzx2mlDIQNa-mC7xYlqRzbqyBumO7Os"

dig TXT _acme-challenge.faultline.com @ns4.faultline.com +short
"E1T480cPTm56nzx2mlDIQNa-mC7xYlqRzbqyBumO7Os"

I don't know DNS as well as some of the others but I know that they should all respond the same. Let's Encrypt servers will check any of the authoritative servers. From the error it looks like it checked ns3 or ns4.

3 Likes

Yeah, I only checked ns2.faultline.com since it was the one in the DNS SOA Record.

1 Like

I get the same results as @MikeMcQ Home server with private IP address - #8 by MikeMcQ

$ nslookup
> server ns2.faultline.com.
Default server: ns2.faultline.com.
Address: 69.164.209.149#53
> faultline.com
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

Name:   faultline.com
Address: 69.164.209.149
> set q=soa
> faultline.com
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

faultline.com
        origin = ns2.faultline.com
        mail addr = root.ns2.faultline.com
        serial = 202209182
        refresh = 7200
        retry = 3600
        expire = 864000
        minimum = 7200
> set q=txt
> faultline.com
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

faultline.com   text = "v=spf1 a mx ip4:69.164.209.149 -all"
> _acme-challenge.faultline.com.
Server:         ns2.faultline.com.
Address:        69.164.209.149#53

_acme-challenge.faultline.com   text = "Y8-QfJXqlE2_VG_xlhoco55e60JneJRqZ9ujGEfXbIU"
>
> server ns1.faultline.com.
Default server: ns1.faultline.com.
Address: 69.164.209.149#53
> _acme-challenge.faultline.com
Server:         ns1.faultline.com.
Address:        69.164.209.149#53

_acme-challenge.faultline.com   text = "Y8-QfJXqlE2_VG_xlhoco55e60JneJRqZ9ujGEfXbIU"
> server ns3.faultline.com.
Default server: ns3.faultline.com.
Address: 173.255.229.77#53
> _acme-challenge.faultline.com
Server:         ns3.faultline.com.
Address:        173.255.229.77#53

_acme-challenge.faultline.com   text = "E1T480cPTm56nzx2mlDIQNa-mC7xYlqRzbqyBumO7Os"
>  server ns4.faultline.com.
Default server: ns4.faultline.com.
Address: 23.92.20.44#53
> _acme-challenge.faultline.com
Server:         ns4.faultline.com.
Address:        23.92.20.44#53

_acme-challenge.faultline.com   text = "E1T480cPTm56nzx2mlDIQNa-mC7xYlqRzbqyBumO7Os"
>

And DNS Lookup - Check DNS Records see it as well

1 Like

The answers suggesting using an API are suggesting life would be easier if you had a way to let your ACME client perform the DNS updates on your behalf. It doesn't have to actually be an API. It could just as easily be a shell script running sed/awk and restarting named. There are existing plugins that also use RFC2136 dynamic updates if you prefer. You also don't have to set this up right away since you still seem to be in the evaluation phase of using Let's Encrypt and are still dealing with apparent replication issues between your public DNS servers.

The TTL of the _acme-challenge record is largely irrelevant. The validation servers only cache results for the lesser of either the TTL value or 60 seconds.

All of your nameservers currently agree on the SOA serial number, yet are providing different answers for the _acme-challenge.faultline.com TXT record as your own checks confirmed. This usually indicates a problem with your zone files. You haven't said how your nameservers replicate their data between each other or whether you just modify them all by hand. But the SOA refresh window is only 2 hours and it has been 5 hours since others checked the _acme-challenge values. So replication delay seems unlikely at this point unless you're doing something out of band from normal BIND zone transfers.

Bottom line, all 4 nameservers must reply with the same value at the time the validation servers make the query. There's no downstream caching or TTLs to worry about. The validation servers will be directly querying (at random) one of your 4 nameservers.

If ns1.faultline.com and ns2.faultline.com are the same host (they currently resolve to the same IP) and that is the only host getting the updated TXT value, you have a 50/50 chance of any given validation attempt succeeding. Due to the multi-perspective validation that Let's Encrypt uses, there will be 3-5 total queries made (I forget the exact number) that must all succeed.

3 Likes

Note: Although 4 servers are listed, only 3 IPs are returned

faultline.com   nameserver = ns1.faultline.com
faultline.com   nameserver = ns2.faultline.com
faultline.com   nameserver = ns3.faultline.com
faultline.com   nameserver = ns4.faultline.com
ns1.faultline.com       internet address = 69.164.209.149
ns2.faultline.com       internet address = 69.164.209.149
ns3.faultline.com       internet address = 173.255.229.77
ns4.faultline.com       internet address = 23.92.20.44

[ns1.faultline.com & ns1.faultline.com = SAME IP]

2 Likes

Thank you for the time to look at things. I found the issue with the differing values which was that I forgot to increment the serial number the last time.

I did find that by using a third party resolver that the servers also cache clients. So I needed to restart the all the servers not just propagate the settings.

I the cert issued now. Now I have to see how it works.

Thanks,
Carl

3 Likes

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