Frontdoor Certificate Validation Process

Copper Contributor

Hi

I'm working as an IT Architect for a Web-Agency, and I'm faced with a challenge on how to use the certification service with Front Door.  


With every Environment and Platform, I'm deploying we also deploy a public DNS zone. 
This helps a lot to deploy and provide services and changes independently to other DNS systems and zones. 
So for example, I deploy a platform 'alpha' with two environments.
I would deploy two DNS zones:

  • alpha.dev.dns.com
  • alpha.prod.dns.com

From now on, I can deploy services for these platforms, change public IPs etc. without having to care about the end-customer DNS. The endcustomer is just pointing his DNS www.customer.com to www.alpha.dev.dns.com
(lets not talk about SOA records for now :) )

For Frontdoor this workes quite well. 
So during the Front Door provishioning I create dns records for every domain pointing to the Endpoint www-customer-com.xyz.azurefd.net.

DNSTypeValue
www.customer.comCNAMEwww.alpha.dev.dns.com
www.alpha.dev.dns.comCNAMEwww-customer-com.xyz.azurefd.net
_dnsauth.www.customer.comCNAME_dnsauth.www.alpha.dev.dns.com
_dnsauth.www.alpha.dev.dns.comTXT<validationcode>


So the validation process runs his check on _dnsauth.www.customer.com - follows the CNAME to _dnsauth.www.alpha.dev.dns.com and validates the certificate request.

Now there is an issue with the re-validation process. Because Front Door suddenly can not handle the fact that www.customer.com is a CNAME and not directly pointing to the Front Door Endpoint:  www-customer-com.xyz.azurefd.net.

This means, to keep valide Certificates, we have to introduce a process to revalidate the certificate requests and update the DNS records. Fortunatly they are in our own hands - and not on the customer domain. But do you know why this limitation existis? and what do you think about this architecture?

 

0 Replies