The final step after I added the SSL cert and key details ( and the TXT record to the zone file on my server ) was the “verify” button… which succeeded, and reported no errors. The subdomain then went into limbo for a few hours while things clunked through DNS, until the subdomain reverted to the default index page on my web server. 48 hours later that’s all it does, Is this expected behaviour?
The Custom Domain was meant to solve the Third Party Cookie issue, but it’s achieved nothing. The sign-on widget still fails the same as before. I’m about 10 days into this now, and I don’t seem to be making any progress. And yes… I raised a ticket last week.
I believe I found the support case you mentioned but it looks to be about a separate issue.
If you are having trouble setting up the custom domain in addition to your other problem, can you file a second support case so that someone can help you with this issue as well?
Thanks for the reply. The custom domain was supposed to solve the third-party cookie issue, so in essence it was part of that ticket. Unfortunately it’s has introduced a new problem and not resolved the first one. I’ll raise a ticket for that and see how it goes. I’m just conscious of raising tickets for all the “fixes” that introduce new issues.
We ran into a challenge along those lines that wasn’t uncovered until we started working with OIDC & JWT tokens. Turns out that we’d neglected to change the “Issuer” associated with our Authz server. Once we changed that it started working much better. Hope this helps.
Thanks for the reply. I read somewhere else that any custom auth servers you set up before adding a custom domain won’t work on it afterwards, but they’ll still work on the okta.orgname url. I also expected that the api endpoint would serve from the custom domain, I can see that happening but there’s no mapping at domain level - so calls to the auth server meet with 404’s. There’s a deeper issue with the subdomain I set up not serving the okta content, still haven’t got to the bottom of that yet.
We were also having issues getting SAML to work properly. This issue is listed under the caveats at the following link. Before you begin | Okta Developer Synchronizing the AUTHZ to use the custom URI also resolved that problem.
Thanks for the reply. I tried creating an auth server using the custom domain last week, but it always responded with a 404. That’s the core issue… that after adding all the certificate and zone file details, and getting a notification that the verification was successful, the subdomain on my server NEVER serves any okta endpoints. How does anybody actually get this working in a local dev environment? Surely you’ll need self-signed SSL, a subdomain and a primary domain, local DNS, and zone file hosted on your dev server at the very least?
So I worked it out, a few days after okta support stopped updating the open ticket. I don’t really understand what happened, but I decided to go in and set up the custom domain from scratch again. I was about to delete it when I saw I had the option to verify it again, so I tried that. It came up with a CNAME entry that I had to add - but I couldn’t have a CNAME AND a TXT Record for the subdomain. So I deleted the TXT record and added the CNAME. 10 minutes later… the Okta sign in appeared on my subdomain, and once logged in, it behaved just as if I had gone to the original Okta assigned URL. Who knows if this will help anyone, at least I can say it’s possible and it does work. Eventually.
