3

Our team recently decided to reconfigure an old Windows Server 2012 group of servers/network to set it up for production use. We recently renamed the old domain for all the servers, reattached each server to the domain, and purchased and uploaded/configured a new wildcard certificate for the environment. One issue we have run into is references to the old domain name in various places. We have had to detach and reattach servers multiple times to get the desired result of an updated domain name (this was an issue in most cases). We appear to have been successful in this endeavor.

The current issue which I cannot resolve is an issue related to a name mismatch and certificate warning. In my case, I am connecting via VPN + private IP address + RDP to the server, but when I connect, the "requested remote computer" name is the private IP address of the server (ex. 10.20.30.20). It should instead be the FQDN of the server (ex. computername.blahblah.com). Since it simply sees an IP address for the server, the "name in the certificate from the remote computer" does not match up (the SANs within the certificate use computername.blahblah.com references).

Note that this mismatch is only occurring on one server in the group. All other servers behave as expected with a proper computer name which does match a SAN listed in the certificate.

How can I update the "requested remote computer" name of the server so that I do not get any more name mismatches with my certificate? See error screenshot below:

enter image description here

nairware
  • 309
  • 2
  • 9
  • 17

1 Answers1

5

Well, the easy way to do this would probably be to connect to the server by hostname, rather than IP so you don't see that warning.

Alternately, ignore it. You can ignore it and connect, which in this case wouldn't pose a security risk, since you know the server you think you're connecting to is the server you're trying to connect to, and not some sort of MITM (man in the middle) attack.

The proper way, of course, it to reissue the certificates on your machines. You can include the short name and IP address in the SAN (subject alternate name) field on the certificate, so that the server identifies itself with a name that matches the certificate any way you connect to it.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • My only concern is that, while your solution will get rid of the problem, I am still lost as to why one server on the network handles the certificate just fine...while this server has the mismatch issue. I am just not sure if there is something else wrong with the server, like some other reference to the old domain. I have never done a domain rename before, and never worked with W2012 either, so I am hesitant to implement workarounds when a more fundamental problem might be looming. – nairware Apr 22 '14 at 03:31
  • @nairware Look at it. `Requested remote computer: [IP address] Name in the certificate from the remote computer: [hostname.com]` Your MSTSC client is being told it's connecting to "[IP address]," but the certificate dones't have that IP address as a valid name for that server. That's all. Connect by name, and that should resolve the issue, or add the IP as a subject alternative name. I can't say if there are traces of the old domain hanging around, but I can say that this doesn't look like a symptom. – HopelessN00b Apr 22 '14 at 03:42
  • Well, how come there is no issue with a mismatch related to the other servers--none of which have an explicit listing within the certificate which includes their private IP addresses? I've taken the same approach for all servers, but four of them work fine, and one of them gives this name mismatch warning/error. – nairware Apr 22 '14 at 05:27
  • @nairware How would I know? You're the one who's got the certificates and the servers; who can look and see what's different about this specific server and/or this specific certificate. – HopelessN00b Apr 22 '14 at 05:39