2

My company "ourcompany" owns a 2nd level DNS domain name: ourcompany.org. We currently use this domain, as well as www.ourcompany.org and feature1.ourcompany.org, and have an SSL certificate generated for both these 3rd level domains.

Then we subscribed to a third party hosted service, hosted at ourcompany.thirdparty.org. They handle SSL and have a certificate whose subject is thirdparty.org and have the Subject Alternative Name *.thirdparty.org.

This 3rd party company also provides a functionality to add a custom domain. So we added a CNAME record in our DNS configuration, and now we have feature2.ourcompany.org pointing to ourcompany.thirdparty.org. Obviously at this point SSL is not working when accessing feature2.ourcompany.org.

Then the 3rd party company also asked us to ad TXT DNS entries to prove we are owners of the domain, and they were somehow able to update their SSL certificate and add the following Subject Alternative Names: ourcompany.org and *.ourcompany.org.

  • How is that not a potential source of Man in the Middle attack? (the 3rd party company can now impersonate us on any of our domains)
  • How can an arbitrary 3rd party company generate valid SSL certificates including SAN pointing to a domain they don't own? (their SAN include a lot more things than the CNAME domain record we added)
  • Did the certification authority allowed our domains as SAN because of the CNAME record pointing to their domain (in this case, how come the SAN included way more domains than just feature2.ourcompany.org), or because of the TXT entry (in this case, could someone point me to a resource explaining this process)?
Improve this question

2 Answers 2

Reset to default
2

After reviewing our DNS configuration, it seems that the certification authority validated the SAN entries in the 3rd party company certificate because of one of the TXT entries they asked us to add: globalsign-domain-verification=XXXXXXX, where XXXXXXX is a key provided by GlobalSign to the 3rd party company (documentation about this GlobalSign feature is hard to find but I could find something here). This answers the 2nd and 3rd questions.

As for the 1st one, it seems that the TXT entry being set to the 2nd level domain, the 3rd party company is now authorized to include the 2nd level domain as well as any 3rd level domain under it in the SAN entries of their certificate.

Improve this answer
0

the third party company propably needs a verification to prove that you have access to the domain (much like godaddy verifies on simple ssl certs)

this does not mean that they have access to your domain name and/or can take over your domains. this also does not mean that they can do a mitm on connections established via your own cert. it's just a seperate cert and when you point with a matching dns records to their servers they will handout the cert. handling many certs on a single host/address is quite commin since sni (server name indication) is quite well supported today.

Improve this answer
2
  • Their cert is separate, so indeed, if the SSL negociation is already made between the user agent and our company's server, they won't be able to sneak in between. But they can totally impersonate our domains if they intercept the communication from the beginning, using DNS cache poisoning, or if they control the user's LAN/WAN (enterprise network), or by selling the cert to an entity that can do this, etc.
    – Maxime Rossini
    Feb 23, 2016 at 8:37
  • Exactly - you can reduce the risk by limiting the issued certificate to the desired subdomain. But when you're talking about dns cache poisoning they may also be able to poison the cache in order to pass the domain validation by setting a txt record - if they've that power the cert itself is not the greated risk :-)
    – Daniel Nachtrub
    Feb 23, 2016 at 8:46

You must log in to answer this question.

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