Score:-1

SSL cert fails when subdomain is an A Record of another host

gh flag

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.

Score:0
fr flag

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.

biscuitstack avatar
gh flag
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?
vidarlo avatar
ar flag
It should, but you are requesting one for API.domaina.
user1686 avatar
fr flag
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.
biscuitstack avatar
gh flag
@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.
user1686 avatar
fr flag
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.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.