0

I have two servers in an Active Directory domain. Both servers have apps that run in Tomcat. I'm ordering PKI certificates for these two servers.

The servers are members of the AD domain "ourInternalNetwork.com". The majority of systems on this domain are not accessible from the public Internet. These two servers will be accessible from the 'Net.

For political reasons, we have not registered "ourInternalNetwork.com" Rather, we have the domain "ExternalNetwork.com" When we go into the system properties, the servers identify themselves as "server1.ourInternalNetwork.com" and "server2.ourInternalNetwork.com". However, we want Internet-connected users to reach the servers by "server1.externalNetwork.com" and "server2.externalNetwork.com"

This requires a Subject Alternative Name, right? My understanding is that if we create CSR's with no SAN, the CSR will be for "server1.ourInternalNetwork.com", and our CA won't issue us a certificate for "server1.ExternalNetwork.com"? But if we specify a SAN, then our CA will issue a cert for both "server1.ourInternalNetwork.com" and "server1.ExternalNetwork.com".

Do I have that right?

Michael Cornn
  • 269
  • 3
  • 16

2 Answers2

2

If the application running on your servers will only be accessed from the external interface, you don't need to bother with SANs at all. Just purchase a standard certificate for the external name and be done with it. This can also work even if internal people are accessing the application, you'd just tell them to use the external name when connecting. There's nothing that requires pairing the internal identity of the server to the external name of the application.

If you need the application to be accessible using both the internal and external name, you won't be able to do it with a single certificate unless you run your own CA. As Grant mentioned, no public CA will issue you a cert for DNS domains you don't own. With your own CA, you can technically generate a certificate that contains both names. You could even generate a certificate for "google.com" if you really wanted to. But external clients you don't manage will get certificate warnings unless they choose to add your CA's certificate to their trusted roots list. That's why you typically choose to use a public CA to begin with; default trust.

I'm not sure how or if it works with Tomcat, but hypothetically you could host the application on separate interfaces within the same server. The internal interface would use a certificate you generate yourself. The external interface would use the purchased certificate.

Ryan Bolger
  • 16,755
  • 4
  • 42
  • 64
  • That's really good news. Yes, we'll have both internal and external clients accessing the servers by their "externalnetwork.com" hostname. We've set up a split DNS for that purpose. – Michael Cornn May 08 '14 at 12:14
  • What I'm curious about: Our AD domain will remain ourinternalnetwork.com (it's a long story). Thus, if you went into the properties for these servers, they would identify themselves as "server1.ourinternalnetwork.com." They don't "know" the externalnetwork.com domain exists. So...when I create the CSR, will it have "server1.ourinternalnetwork.com" in the request? And will our CA refuse to issue a cert for "server1.externalnetwork.com"? – Michael Cornn May 08 '14 at 12:16
  • Forgive me if these questions sound silly. I want to make sure I have a full understanding before I go to my management. – Michael Cornn May 08 '14 at 12:17
  • When you generate the CSR, it's going to be a custom request where you put whatever name you want as the common name. It's not going to include the internal name unless you add it. That sort of thing only comes into play if you're using an internal Enterprise CA with certificate templates that auto-generate names based on AD data. The site you're purchasing the cert from should also have pretty explicit instructions on how to generate the CSR properly. – Ryan Bolger May 08 '14 at 17:07
1

If you are not the current registrant of ourinternalnetwork.com no legitimate CA should issue you a certificate for it or its subdomains under any circumstances.

don't use domains you don't own.

Grant
  • 17,859
  • 14
  • 72
  • 103
  • I should have clarified. We own both domain names, ourinternalnetwork.com and externalnetwork.com. It's a long story, but we changed our organization name form ourinternalnetwork.com to externalnetwork.com. Although management doesn't want to register any more records for ourinternalnetwork.com, we'll stay the owners of the domain. – Michael Cornn May 08 '14 at 12:13