Plan requirement
| Subscription | Any plan |
| Access | Admin |
Sign-in failing on your own domain but working on the Zendesk address. It is nearly always DNS rather than Zendesk, and there is a clock on it: if the misconfiguration is still there when your certificate comes up for renewal, typically within 30 days, Zendesk removes the invalid host mapping.
Symptoms
- An error when signing in on the mapped domain, but not on the Zendesk address.
- A certificate warning.
- Sign-in loops back to the sign-in page.
Start with the quick test
Try signing in on the Zendesk address. If that works and the mapped domain does not, the fault is in the mapping, the certificate or a redirect address, which rules out most of Zendesk immediately.
One: the CNAME record
A CNAME has to point your host-mapped domain at subdomain.zendesk.com. Check it with a DNS lookup, and check that it has propagated worldwide rather than only where you are sitting.
A DNS change made elsewhere in the business can remove or alter that record without anybody connecting the two events, which is why this breaks on days when nobody touched Zendesk.
Two: the CAA record
This is the one people do not think of. Zendesk provisions the certificate through Let's Encrypt, so if your domain publishes CAA records at all, issue letsencrypt.org has to be among them. Without it, the certificate authority is not allowed to issue and the certificate cannot be obtained.
If you see a message saying Zendesk was unable to obtain a certificate from Let's Encrypt, fix the CAA record and then use Retry certificate request.
What the certificate does on its own
Zendesk renews the provisioned certificate automatically before it expires, so an expiry date is rarely your answer unless you uploaded your own certificate. One certificate covers up to 100 host-mapped domains.
Adding, updating or deleting any host-mapped domain makes Zendesk remove the current certificate and replace it. So a change to one domain is a moment when all of them are reissued, and a CAA or CNAME problem that was harmless yesterday surfaces then.
Three: the sign-in redirect
Where single sign-on is involved, your identity provider has a redirect address registered. If it points at the Zendesk address while people arrive on the mapped domain, sign-in fails or loops. In our experience that is the usual cause of a loop rather than an error.
The same mismatch happens without an identity provider when links in emails, articles and your website point at one address while the other is in use. People switch between the two mid-flow and lose the session.
If it persists
Send pluscloud support the domain, the exact error, and whether the Zendesk address works. Certificates and DNS usually involve whoever runs your domain, so expect them to be part of the fix, and start that conversation before the 30 days are up.
Comments
0 comments
Article is closed for comments.