We have a specialized IIS 6.0 web server running under Server 2003 that one of our applications uses to transfer information between sites. The site has a FQDN and the certificates are loaded properly on both the server and what would consider to be the "client" machine.
The "client" uses an automated process to access the web server. However, due to configuration constraints, the "client" cannot use the FQDN, so it must access the system via the IP address.
The problem is that now the system hangs up on the "There is a problem with this website's security certificate" message. Since this is an automated process, there is no way to "click" on "Continue to this website (not recommended)" link.
If you do go to the FQDN, the site works fine. Unfortunately, that is not an option with the custom program we are using. We must access via IP address only.
I see no way to issue a certificate based on IP address versus FQDN. Does anyone know a registry setting or other fix that will always ignore the "Continue to this website...." message?
Thanks,
Joe
Note that you need SAN enabled on the CA for this to work. Refer to this document for more info:
http://support.microsoft.com/kb/931351
If you are using public certs, consider a Unified Communications Certificate (UCC or UC Cert), sometimes referred to as multi-domain certificate. Pretty much the same thing - you submit the CSR and then they provide a text field where you can just type in on separate lines what you want to be valid - these can be hostnames, IP addresses, DNS names/aliases, etc. They cost a bit more but worth it when you need one. Most commercial CAs will offer these (Verisign, Comodo, GoDaddy, etc.).