I want to add an extra layer of security/validation into our app/network. I plan to do some mTLS in which we will provide customers with a certificate to use in the TLS handshake. However, I want the customer to pass proof of domain ownership when they initiate the request. After successfully passing the checks (including some extra onboarding things) they can perform the mTLS to get data.

I am thinking of requiring admins to upload a DV certificate which they will send to initiate a request. Another option (or an addition to the DV cert) is to check their DNS for a txt record so we can verify the domain. So if stackexchange.com join our network I want to ensure the real stackexchange is asking for data.

Would it be too cumbersome for an admin to provide their DV certificate when onboarding to our app? Would DNS check be the best option that I can check on each initiation request?

  • A while back I worked on a project that validated emails by querying the mailbox, the DNS part of that request proved unpredictable, sometimes taking up to 2 seconds, so that is a concern to take into account
    – Purefan
    Aug 2, 2022 at 21:26

1 Answer 1


You should look at DANE and DNS TLSA records...

A very good recent introduction on it: https://indico.dns-oarc.net/event/43/contributions/928/attachments/901/1648/dane-overview-shumon.pdf ; in short it allows to publish in the DNS, properly, either a certificate, or a key, or a CA certificate. That allows to tie a specific name to a specific certificate/chain of certificates.

Far better than any TXT records. And this is used in the SMTP world.

  • omg this is awesome. I think this is exactly what I need. Reading about it now ...
    – Decrypter
    Aug 2, 2022 at 22:26
  • so the admin would store their public certificate we provide them as a TLSA record. When they initiate the request we check if that record exists, pull the certificate and verify?
    – Decrypter
    Aug 2, 2022 at 22:31
  • 1
    Typically a client connects to some endpoint using TLS and gets a certificate. For the given name being contacted, TLSA records would specify which certificate is to be expected (either specific certificate or any certificate under a CA given in the TLSA record), and hence the connection is aborted if no match. This even allows to work (there are multiple modes defined) completely outside of the current WebPKI. Aug 2, 2022 at 23:17
  • This is cool. For our app I would like to verify the RP with a cert we provide them from our private CA. We can use TLSA and they add our private CA fingerprint. In order to verify they need to have an https server like my-app-verify.example.com (returns the cert we provide) and calling that will either be successful or aborted. Is that correct?
    – Decrypter
    Aug 3, 2022 at 0:57
  • The problem with this is that RPs will require their domains to be DNSSEC which isn't guaranteed and I can't ask them to enable it. I like the certificate within DNS and perhaps I can add a hashed cert to a TXT field and perform some checks on that ?
    – Decrypter
    Aug 3, 2022 at 15:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .