asked on RemoteApp fails due to "bogus" SSL Certificate after local network changes implemented
I recently had to replace my cable modem and firewall device and, as a result, changes were required to reestablish my local network connectivity. With that behind me, RemoteApp applications which had been working correctly for months, are no longer working. The .rdp file appears to start the process as always:![RDP-credential-prompt.jpg]()
I have valid certificates, and even "re-keyed" them after my local network changes, for my Remote Gateway:![Certificate---Valid-Remote-Gateway.jpg]()
and my Remote Host Session:![Certificate---Valid-Host-Session.jpg]()
My problem is that after entering my credentials, the following Remote Gateway error is displayed:![RDP-error-message.jpg]()
When I view the certificate, the following "bogus" certificate is displayed:![Certificate---Bogus.jpg]()
I have no idea why or where this certificate is even coming from. As always, any help would be greatly appreciated!
I have valid certificates, and even "re-keyed" them after my local network changes, for my Remote Gateway:
and my Remote Host Session:
My problem is that after entering my credentials, the following Remote Gateway error is displayed:
When I view the certificate, the following "bogus" certificate is displayed:
I have no idea why or where this certificate is even coming from. As always, any help would be greatly appreciated!
SSL / HTTPSRemote AccessWindows Server 2008
Last Comment
Jim Klocksin
USG is an alternate acronym used by several firewall/UTM for their unified security gateway products. Your replacement firewall is snagging port 443 instead of passing it on to your RDGateway. So look into your firewall configuration. Could be web server protection. Or could be remote management is enabled for public access and it uses 443. Those are common misconfigirarions I see.
You will probably have to define rules in the new firewall to pass the port 443 to your RDP server depending on the firewall you may also have to define the RDP access rule also.
ASKER
Right now, I don't have the new firewall yet (may be coming tomorrow...) and the only firewall I have on my server is the Windows Firewall where I have port 443 set up under my incoming connections. Other than that, I have the XFINITY cable modem that they installed to get me back up on the Internet and the only options that I can see on that are to "block" ports 80 and 443 (which I obviously didn't check off) and, right now, I have the XFINITY cable modem router set to DISABLE FIREWALL. I'm getting a Zoom cable modem router to replace the XFINITY, but that hasn't gotten here yet either. The only conclusion I can come to is that, despite my settings, the XFINITY modem router is putting out that "bogus" certificate, but I don't see any way I can change that (I've already disabled it's firewall capabilities if I can believe what It's telling me!?).....Bottom line, I'm still getting the same error with the same USG certificate!
That's a fair guess. I assume the cable modem is also handling NAT duties, and you usually need to add rules to properly NAT inbound traffic, nut just disable blocking them.
ASKER
Yes, you're right. Since I prefer static IP addresses (small network), I had to change the default IP that came with the cable modem and the only real issue there was that I had been using 192.168.7.55 as my Gateway IP, XFINITY forced me to change that to 192.168.7.1 AND, in order to get my network connecting correctly, I had to turn off IPV6 on all of my computers.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
In this case, since, previously, I was always able to connect to my own network via RDP FROM my own network, I just assumed that I had a problem with this functionality. Since I can't test this without contacting a client and have them test it, I was convinced that the problem would affect everyone, but, in the end, it turned out that I NEED to have an actual client test this before I make any assumptions!