# Render custom domain TLS: DNS records, CAA and wildcards

> Add a custom domain to a Render service with managed TLS: apex vs www records, CAA for letsencrypt.org and pki.goog, wildcard CNAMEs and fixes.

Source: https://ssl.sh/guides/render-custom-domain-tls/
Last updated: 2026-11-10

Render gives every custom domain a free, fully managed TLS certificate from Let's Encrypt or Google Trust Services, renews it before it expires and redirects HTTP to HTTPS. Add the domain to a web service or static site, create one DNS record per name, then click **Verify**.

Wildcard domains are supported. Render's docs offer no way to upload your own certificate. Steps and screen names follow Render's documentation as of November 2026, using `example.onrender.com` as the service and `example.com` as the domain.

## At a glance

| Question | Render |
|---|---|
| CA for automatic certificates | Let's Encrypt and Google Trust Services |
| Apex (`example.com`) | `ANAME`/`ALIAS` to `example.onrender.com`, or `A` to `216.24.57.1` |
| `www` and other subdomains | `CNAME` to `example.onrender.com` |
| CAA must allow | `letsencrypt.org` and `pki.goog` (`issue`, plus `issuewild` for wildcards) |
| Wildcard certificates | Yes, with `_acme-challenge` and `_cf-custom-hostname` CNAMEs |
| Upload your own certificate | Not offered in the docs |
| Renewal | Automatic |
| Included custom domains | 2 (Hobby), 15 (Pro), 25 (Scale); extra domains $0.25/month each |

## Step 1: Add the domain in the Render Dashboard

Only web services and static sites accept custom domains. Open the service, go to **Settings > Custom Domains**, click **+ Add Custom Domain**, enter the name and click **Save**.

Render pairs the root and `www` names automatically:

- If you add `www.example.com`, Render also adds `example.com` and redirects it to `www`.
- If you add `example.com`, Render also adds `www.example.com` and redirects it to the root.

Convert internationalized names to Punycode before adding them.

## Step 2: Create the DNS records

First delete any `AAAA` records for the names you add. Render serves custom domains over IPv4, and Render's docs warn that `AAAA` records cause unexpected behaviour.

| Name | Record | Value |
|---|---|---|
| `example.com` | `ANAME` or `ALIAS` (or flattened CNAME) | `example.onrender.com` |
| `example.com` (fallback) | `A` | `216.24.57.1` |
| `www.example.com` | `CNAME` | `example.onrender.com` |

Use the ANAME/ALIAS form if your DNS provider supports it. If the provider adds defaults such as domain forwarding, `dig` shows extra values; disable them.

On Cloudflare, Render asks for a CNAME at the root as well (Cloudflare flattens it), with **Proxy status** set to **DNS only** and the SSL/TLS mode set to **Full**. Proxying can be turned on after the Render Dashboard shows the certificates as issued.

## Step 3: Check CAA records

Existing CAA records must allow both of Render's CAs, plus `issuewild` lines for a wildcard domain. With no CAA records, skip this step.

```dns
example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "pki.goog"
example.com.  3600  IN  CAA  0 issuewild "pki.goog"
```

Render may use either CA, so a policy that lists only one of them can block a later issuance or renewal even if the first certificate worked. Check the result with the [CAA checker](https://ssl.sh/tools/caa-checker/).

## Step 4: Verify the domain

Back in **Custom Domains**, click **Verify** next to the domain. If verification succeeds, Render issues the certificate and marks the domain as verified. If it fails, DNS has probably not propagated yet: wait a few minutes and try again. Render suggests flushing public resolver caches (Google Public DNS, Cloudflare 1.1.1.1, OpenDNS) after changing records, especially after a nameserver change, to speed up both verification and certificate issuance.

## Wildcard domains

Add `*.example.com` like any other domain, then create all three CNAMEs:

| Name | Value |
|---|---|
| `*` | `example.onrender.com` |
| `_acme-challenge` | `example.verify.renderdns.com` |
| `_cf-custom-hostname` | `example.hostname.renderdns.com` |

The `_acme-challenge` record lets Render complete the Let's Encrypt DNS challenge for issuance and renewal; `_cf-custom-hostname` lets Cloudflare, Render's DDoS protection provider, validate the hostname. The root domain must also point to Render, or the wildcard configuration fails. On Cloudflare with proxying on and only the wildcard added, the root's traffic would be sent to the same Render service, so set the root record to DNS only.

## Your own certificate

Render's TLS page says certificates are fully managed with no setup, and none of its custom domain pages describes an upload. Plan on the managed certificate. If you need an OV or EV certificate or a particular CA, terminate TLS on a proxy or CDN in front of Render that accepts custom certificates.

## Verify

The issuer should be Let's Encrypt or Google Trust Services, and an HTTP request should return a redirect to HTTPS. Check the domain from outside with the [SSL checker](https://ssl.sh/tools/ssl-checker/), or from any terminal:

```bash
curl ssl.sh/example.com
```

Confirm what Render serves:

```bash
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -ext subjectAltName -dates
curl -sI http://example.com | head -n 3
```

## Renewal

Render renews certificates automatically before their expiration date, so there is no cron job to write. Renewal depends on the same things as issuance: DNS still pointing at Render, CAA still allowing both CAs, and, for wildcards, the `_acme-challenge` CNAME still in place. Shorter lifetimes are coming (Let's Encrypt's default goes to 64 days on February 10, 2027 and 45 days on February 16, 2028), which means more renewals and more chances for a DNS change to break one. Add the domain to [ssl.sh monitoring](https://ssl.sh/monitor/) (in development).

## Troubleshooting

- **Verification fails**: DNS has not propagated or is wrong. Compare `dig example.com` and `dig www.example.com CNAME` with the values above, remove `AAAA` records and provider defaults, and click **Verify** again.
- **502 Bad Gateway right after verification**: Render may still be updating routing rules. Wait a few minutes.
- **Certificate never issues behind Cloudflare**: set the records to **DNS only** until Render shows the certificate as issued; keep the `_acme-challenge` record unproxied for wildcards.
- **Wildcard configuration fails**: the root domain points somewhere other than Render, or one of the three CNAMEs is missing.
- **CAA errors**: add both `letsencrypt.org` and `pki.goog`; see [CAA record prevents issuance](https://ssl.sh/errors/caa-record-prevents-issuance/).
- **Browser shows the wrong name** ([NET::ERR_CERT_COMMON_NAME_INVALID](https://ssl.sh/errors/net-err-cert-common-name-invalid/)): some resolvers still return an old record. Lower the TTL next time and flush public resolver caches.