-1

Please excuse any wrong terminology here. If it feels I'm using the wrong term, I possibly am.

Previous scenario:

  • I have a domain and subdomains DOMAINA, * .DOMAINA on my domain provider, pointing to a linode name server ns*.linode.com
  • I hosted SITEA on a linode server LINODESERV and used linodes DNS records.
  • I ran letsencrypts certbot on LINODESERV and used a linode plugin to generate certificates using txt records. This worked fine

New scenario:

  • I've a new vercel server that handles everything but API requests API requests still occur on LINODESERV

  • The main DOMAINA and all *.DOMAINA subdomains are now handled by vercels domain settings, which also handle all SSL certification

  • I have an A record on the vercel domain settings, api.DOMAINA that points to the LINDODESERV ip address. This works fine and LINODESERV handles any api.DOMAINA requests

The problem:

I can no longer renew the SSL cert for api.DOMAINA.

Symptoms:

Running the usual renew shows that txt records are created on the LINODESERV. However, certbot reports:

DNS problem: NXDOMAIN looking up TXT for _acme-challenge.api.DOMAINA - check that a DNS record exists for this domain

Possibly the problem:

Previously, my domain provider was pointing directly to ns1.linode.com, now it points to ns1.vercel.com and vercel uses an A record to point to api.DOMAINA.

I feel like certbot is failing to reach a TXT record challenge because of this? But I can't figure out why, or how to remedy it.

biscuitstack
  • 153
  • 1
  • 7

1 Answers1

0

I can't figure out why

Because you still have Certbot configured to use the Linode DNS service plugin, but your DNS zone is no longer at Linode, it's now at ns#.vercel.com – meaning that you need to make Certbot add/remove the TXT records via Vercel's API (if it exists).

The A/AAAA records and the location of the actual server do not matter. Those records only inform clients where to connect for other protocols – they do not allow the server to handle DNS requests for subdomains (that's done via NS records).

If Vercel doesn't have an API that could be used by Certbot, create a subdomain zone at Linode (e.g. "acme.example.com"), add NS records at Vercel to delegate it, and add a CNAME record at "_acme-challenge.api.example.com" pointing to somewhere under that sub-zone. Then continue using Certbot's Linode DNS plugin.

user1686
  • 10,162
  • 1
  • 26
  • 42
  • If I'm understanding you correctly, vercel does have a wildcard SSL certificate in place for both DOMAINA and *.DOMAINA. Shouldn't this cover api.DOMAINA? – biscuitstack Apr 07 '23 at 13:20
  • It should, but you are requesting one for API.domaina. – vidarlo Apr 07 '23 at 13:23
  • It _could_ cover "api.DOMAINA", yes, but it doesn't sound like you are _using_ that certificate yet (based on the fact that you're still running Certbot to get a certificate from LE instead). Vercel cannot unilaterally set up SSL for your external servers, neither as a domain registrar nor as a DNS host – the certificate has to be installed on your Linode server somehow. – user1686 Apr 07 '23 at 13:23
  • @user1686 So, to summarize: There must be a cert for the linode server stored locally there. The vercel server cannot use its *.DOMAINA cert to satisfy a cert for api.DOMAINA if its an A record point to the linode server ip address. Only for requests local to the vercel server. Correct? If so, the fact that I have a cert on the linode server for api.DOMAINA is correct. The problem is that it needs to be configured relative to the vercel server, whereas its configure as though its the initial destination from the nameserver. – biscuitstack Apr 07 '23 at 13:39
  • Yes, the certificate (and its private key) must be directly accessible to the system that's actually talking SSL. If Vercel doesn't allow using the certificate with external systems, you need to continue using LE with Certbot as before; the only difference is that _DNS_ now goes through Vercel first. – user1686 Apr 07 '23 at 13:50