Is it possible to talk to server at https://<server IP>, whereas the server certificate subject is <server host name>? RRS feed

  • Question

  • Dear ladies and sirs.

    I have a web application with configured SSL security. The web app is accessable fine using the https://<server host name> address. There is a server certificate with the subject name of <server host name> which is deployed at the Default Web Site.

    Now, I try to access the server at https://<server IP> and it fails, despite the fact that pinging <server IP> reaches the right server machine.

    When I disable SSL security, the server is accessable just fine both at http://<server host name> and http://<server IP>, so the problem is clearly related to the security.

    How can I enable SSL security while preserving the ability to reach the server both by its host name and by its IP address?


    Sunday, May 22, 2011 3:11 PM

All replies

  • Anyone?
    Monday, May 23, 2011 6:09 PM
  • How are you doing SSL handshake?

    I am not sure what do you mean "disable SSL security", how you implement that? If you did not write the SSL handshake code, which library are you using?

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Tuesday, May 24, 2011 6:12 PM
  • I am using WCF client server application.

    When SSL is enabled, I use the SSL_CompressedBinding custom binding - see  below:


      <binding name="CompressedBinding" receiveTimeout="00:30:00" sendTimeout="00:30:00" openTimeout="00:00:02">
      <gzipMessageEncoding innerMessageEncoding="binaryMessageEncoding" binaryMaxQuotaSize="2147483647" />
    <httpTransport maxReceivedMessageSize="2147483647" decompressionEnabled="true"/>
    binding name="SSL_CompressedBinding" receiveTimeout="00:30:00" sendTimeout="00:30:00" openTimeout="00:00:02"> <gzipMessageEncoding innerMessageEncoding="binaryMessageEncoding" binaryMaxQuotaSize="2147483647"/> <security authenticationMode="AnonymousForSslNegotiated"> <localServiceSettings maxClockSkew="13:00:00"/> </security> <httpsTransport maxReceivedMessageSize="2147483647" decompressionEnabled="true" requireClientCertificate="false"/> </binding>

    In addition to SSL_ServiceBehavior server behavior - see below:


      <behavior name="ServiceBehavior">
       <serviceMetadata httpGetEnabled="true"/>
       <serviceDebug includeExceptionDetailInFaults="true"/>
      <behavior name="SSL_ServiceBehavior">
        <serviceMetadata httpsGetEnabled="true"/>
        <serviceDebug includeExceptionDetailInFaults="true"/>
         <serviceCertificate findValue="4A9802576616416D06396245681AA8F3FB0FFDBB" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
    By "disable SSL security" I mean the following:
    1. Using the non secure binding CompressedBinding, instead of SSL_CompressedBinding.
    2. Using the non secure server behavior ServiceBehavior, instead of SSL_ServiceBehavior.
    3. Changing addresses from https scheme to http.

    This allows me to switch between SSL and no SSL configurations fairely easy. Of course, there are other details, like installing the server certificate, binding the port 443 to the certificate, etc... But these things, once configured, do not require maintenance.

    Note, that this is not a WCF question. You have asked how do I handle SSL security - I have shown. BTW, the subject name of the server certificate (the one, which thumbprint appears in the config file) is <server host name>, for instance il-mark-lt on my machine. 


    Wednesday, May 25, 2011 6:33 PM
  • You are not authenticate connections, so unless you authenticate users from your binding contract or message, your server is open to MITM attacks.

    WCF uses System.Net for HTTP communication, therefore the handshake is done by System.Net. System.Net provides a way to override SSL handshake via ServicePointManager.ServerCertificateValidationCallback. However, since the certificate is invalid, you have some bad choices in terms of security.

    1 validate the certificate from other means, like making an (probably unsecured since you are having certificate problems) request to the server and validate the certificate there. This will be subject to MITM attacks.

    2 blindly trust certificate with a marching name and issuer. This will be subject to certificate forging.

    3 do not validate server certificates. 

    You probably want to apply message level security if you cannot secure the transport layer. For discussions about WCF's support for message-level security support, visit the WCF forum.

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Wednesday, May 25, 2011 6:58 PM
  • I haven't read through the whole thread in detail... but can you change the server ssl cert to include both the server host name and the ip address? You would put each one in the Subject Alt Name. This would ensure that both methods of contacting the server work.



    Thursday, May 26, 2011 1:51 AM
  • Hello Andrew.

    Thank you for a relevant reply.

    I am pretty ignorant with all related to security, can you show me the makecert command line creating a certificate with both the IP and the host name as its subjects?


    Saturday, May 28, 2011 7:51 PM
  • Hi Markell,
      I'm not that familiar with makecert. I did a quick search and didn't find an obvious way to add a SAN. Maybe someone else knows? However, if you are just trying to create a self signed cert in the machine store then you can use certreq. Here is what you do on Vista+:
    - Create a file call x.inf and put the following in it:
    Signature="$Windows NT$"
    MachineKeySet = True

    %szOID_SUBJECT_ALT_NAME2% = "{text}dns=www.serverhostname.com&dns="


    I'm not 100% sure about using dns= Try it out. You may need to use ip= I'm not really sure. Let me know if dns= doesn't work and I'll look into it some more.

    - Run the command: certreq -new x.inf x.cer


    This will create the cert in the machine my store [and the private key for the machine] and also write out the cert to x.cer. If all goes well then this cert should allow you to connect to the ssl site using dns name or ip address.


    Let us know how this goes!


    Sunday, May 29, 2011 5:18 AM
  • Thanks Andrew.

    I am trying to validate your answer and I have a problem. The certificate with the alternative subject name should not be self signed. It is to be signed by another certificate. How do I modify the INF file to sign the new certificate by another one?


    Thursday, June 23, 2011 3:17 PM
  • Have you looked at certutil -sign

    I think it will let you resign a cert. So I think you could use that go resign the self signed certificate. I'm not sure if the AKI will get set when resigning, but give it a shot. I have never tried it.



    Saturday, July 2, 2011 5:23 AM