HttpClient https request fails using hostname, but works using IP address





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







2















I am new to web stuff in general. Not sure what the issue is here.



I have a machine with IIS running a ASP NET Core REST API on https.
I can confirm the GET is working via Google Chrome on my machine by doing either





  • https://test-machine/api/Example (works)


  • https://10.0.0.21/api/Example (invalid certificate, N.B. this is as expected as the certificate is for "test-machine")


I confirmed the POST action is working using Postman (again ignoring invalid certificate).
Everything is fine till I try and write a client application.



I have the following code.



var ip = Dns.GetHostAddresses("test-machine");
// ip contains the correct IP

using (var hc = new HttpClient())
{
hc.GetAsync(@"https://test-machine/api/Example").Wait();
}


This code fails. I get an System.AggregateException: 'One or more errors occurred.' with 4 exceptions stacked up on top of one another.




  1. HttpRequestException: An error occurred while sending the request.

  2. WebException: The underlying connection was closed: An unexpected error occurred on a send.

  3. IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

  4. SocketException: An existing connection was forcibly closed by the remote host


If I change the code to use the IP instead:



using (var hc = new HttpClient())
{
hc.GetAsync(@"https://10.0.0.21/api/Example").Wait();
}


Then the request works as expected I.e. as with Chrome, I get a certificate problem:




AuthenticationException: The remote certificate is invalid according to the validation procedure.




What am I doing wrong? The Dns is clearly able to get the correct IP, I've seen it in the IPAddress returned by GetHostAddresses. Why is the HttpClient not resolving the IP - or is it resolving the IP with another problem?



I have tried



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;


and



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;


but this makes no difference. Using the



ServicePointManager.ServerCertificateValidationCallback


Also doesn't work as it never reaches the point of calling the callback. It's failing before then.



I suspect the problem is that as I am not familiar with any of this stuff I have missed something important somewhere.



I should note also - this is a .net 4.5.2 Console app. I tried moving to 4.6.1 and this still fails.










share|improve this question

























  • Does the url load in Internet Explorer 11?

    – mjwills
    Nov 16 '18 at 12:55











  • ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; Your cert supports TLS1.2?

    – mjwills
    Nov 16 '18 at 12:56






  • 1





    Honestly, my suggestion in these cases is to get the cert working.

    – mjwills
    Nov 16 '18 at 12:57











  • Unrelated: You're using HttpClient wrong and Using HttpClient As It Was Intended (Because You’re Not)

    – Fildor
    Nov 16 '18 at 13:01











  • @Fildor I am aware of that - it's only an example :)

    – finlaybob
    Nov 16 '18 at 13:03


















2















I am new to web stuff in general. Not sure what the issue is here.



I have a machine with IIS running a ASP NET Core REST API on https.
I can confirm the GET is working via Google Chrome on my machine by doing either





  • https://test-machine/api/Example (works)


  • https://10.0.0.21/api/Example (invalid certificate, N.B. this is as expected as the certificate is for "test-machine")


I confirmed the POST action is working using Postman (again ignoring invalid certificate).
Everything is fine till I try and write a client application.



I have the following code.



var ip = Dns.GetHostAddresses("test-machine");
// ip contains the correct IP

using (var hc = new HttpClient())
{
hc.GetAsync(@"https://test-machine/api/Example").Wait();
}


This code fails. I get an System.AggregateException: 'One or more errors occurred.' with 4 exceptions stacked up on top of one another.




  1. HttpRequestException: An error occurred while sending the request.

  2. WebException: The underlying connection was closed: An unexpected error occurred on a send.

  3. IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

  4. SocketException: An existing connection was forcibly closed by the remote host


If I change the code to use the IP instead:



using (var hc = new HttpClient())
{
hc.GetAsync(@"https://10.0.0.21/api/Example").Wait();
}


Then the request works as expected I.e. as with Chrome, I get a certificate problem:




AuthenticationException: The remote certificate is invalid according to the validation procedure.




What am I doing wrong? The Dns is clearly able to get the correct IP, I've seen it in the IPAddress returned by GetHostAddresses. Why is the HttpClient not resolving the IP - or is it resolving the IP with another problem?



I have tried



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;


and



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;


but this makes no difference. Using the



ServicePointManager.ServerCertificateValidationCallback


Also doesn't work as it never reaches the point of calling the callback. It's failing before then.



I suspect the problem is that as I am not familiar with any of this stuff I have missed something important somewhere.



I should note also - this is a .net 4.5.2 Console app. I tried moving to 4.6.1 and this still fails.










share|improve this question

























  • Does the url load in Internet Explorer 11?

    – mjwills
    Nov 16 '18 at 12:55











  • ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; Your cert supports TLS1.2?

    – mjwills
    Nov 16 '18 at 12:56






  • 1





    Honestly, my suggestion in these cases is to get the cert working.

    – mjwills
    Nov 16 '18 at 12:57











  • Unrelated: You're using HttpClient wrong and Using HttpClient As It Was Intended (Because You’re Not)

    – Fildor
    Nov 16 '18 at 13:01











  • @Fildor I am aware of that - it's only an example :)

    – finlaybob
    Nov 16 '18 at 13:03














2












2








2








I am new to web stuff in general. Not sure what the issue is here.



I have a machine with IIS running a ASP NET Core REST API on https.
I can confirm the GET is working via Google Chrome on my machine by doing either





  • https://test-machine/api/Example (works)


  • https://10.0.0.21/api/Example (invalid certificate, N.B. this is as expected as the certificate is for "test-machine")


I confirmed the POST action is working using Postman (again ignoring invalid certificate).
Everything is fine till I try and write a client application.



I have the following code.



var ip = Dns.GetHostAddresses("test-machine");
// ip contains the correct IP

using (var hc = new HttpClient())
{
hc.GetAsync(@"https://test-machine/api/Example").Wait();
}


This code fails. I get an System.AggregateException: 'One or more errors occurred.' with 4 exceptions stacked up on top of one another.




  1. HttpRequestException: An error occurred while sending the request.

  2. WebException: The underlying connection was closed: An unexpected error occurred on a send.

  3. IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

  4. SocketException: An existing connection was forcibly closed by the remote host


If I change the code to use the IP instead:



using (var hc = new HttpClient())
{
hc.GetAsync(@"https://10.0.0.21/api/Example").Wait();
}


Then the request works as expected I.e. as with Chrome, I get a certificate problem:




AuthenticationException: The remote certificate is invalid according to the validation procedure.




What am I doing wrong? The Dns is clearly able to get the correct IP, I've seen it in the IPAddress returned by GetHostAddresses. Why is the HttpClient not resolving the IP - or is it resolving the IP with another problem?



I have tried



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;


and



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;


but this makes no difference. Using the



ServicePointManager.ServerCertificateValidationCallback


Also doesn't work as it never reaches the point of calling the callback. It's failing before then.



I suspect the problem is that as I am not familiar with any of this stuff I have missed something important somewhere.



I should note also - this is a .net 4.5.2 Console app. I tried moving to 4.6.1 and this still fails.










share|improve this question
















I am new to web stuff in general. Not sure what the issue is here.



I have a machine with IIS running a ASP NET Core REST API on https.
I can confirm the GET is working via Google Chrome on my machine by doing either





  • https://test-machine/api/Example (works)


  • https://10.0.0.21/api/Example (invalid certificate, N.B. this is as expected as the certificate is for "test-machine")


I confirmed the POST action is working using Postman (again ignoring invalid certificate).
Everything is fine till I try and write a client application.



I have the following code.



var ip = Dns.GetHostAddresses("test-machine");
// ip contains the correct IP

using (var hc = new HttpClient())
{
hc.GetAsync(@"https://test-machine/api/Example").Wait();
}


This code fails. I get an System.AggregateException: 'One or more errors occurred.' with 4 exceptions stacked up on top of one another.




  1. HttpRequestException: An error occurred while sending the request.

  2. WebException: The underlying connection was closed: An unexpected error occurred on a send.

  3. IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

  4. SocketException: An existing connection was forcibly closed by the remote host


If I change the code to use the IP instead:



using (var hc = new HttpClient())
{
hc.GetAsync(@"https://10.0.0.21/api/Example").Wait();
}


Then the request works as expected I.e. as with Chrome, I get a certificate problem:




AuthenticationException: The remote certificate is invalid according to the validation procedure.




What am I doing wrong? The Dns is clearly able to get the correct IP, I've seen it in the IPAddress returned by GetHostAddresses. Why is the HttpClient not resolving the IP - or is it resolving the IP with another problem?



I have tried



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;


and



ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;


but this makes no difference. Using the



ServicePointManager.ServerCertificateValidationCallback


Also doesn't work as it never reaches the point of calling the callback. It's failing before then.



I suspect the problem is that as I am not familiar with any of this stuff I have missed something important somewhere.



I should note also - this is a .net 4.5.2 Console app. I tried moving to 4.6.1 and this still fails.







c# https dotnet-httpclient






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 16 '18 at 13:18







finlaybob

















asked Nov 16 '18 at 12:52









finlaybobfinlaybob

530825




530825













  • Does the url load in Internet Explorer 11?

    – mjwills
    Nov 16 '18 at 12:55











  • ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; Your cert supports TLS1.2?

    – mjwills
    Nov 16 '18 at 12:56






  • 1





    Honestly, my suggestion in these cases is to get the cert working.

    – mjwills
    Nov 16 '18 at 12:57











  • Unrelated: You're using HttpClient wrong and Using HttpClient As It Was Intended (Because You’re Not)

    – Fildor
    Nov 16 '18 at 13:01











  • @Fildor I am aware of that - it's only an example :)

    – finlaybob
    Nov 16 '18 at 13:03



















  • Does the url load in Internet Explorer 11?

    – mjwills
    Nov 16 '18 at 12:55











  • ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; Your cert supports TLS1.2?

    – mjwills
    Nov 16 '18 at 12:56






  • 1





    Honestly, my suggestion in these cases is to get the cert working.

    – mjwills
    Nov 16 '18 at 12:57











  • Unrelated: You're using HttpClient wrong and Using HttpClient As It Was Intended (Because You’re Not)

    – Fildor
    Nov 16 '18 at 13:01











  • @Fildor I am aware of that - it's only an example :)

    – finlaybob
    Nov 16 '18 at 13:03

















Does the url load in Internet Explorer 11?

– mjwills
Nov 16 '18 at 12:55





Does the url load in Internet Explorer 11?

– mjwills
Nov 16 '18 at 12:55













ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; Your cert supports TLS1.2?

– mjwills
Nov 16 '18 at 12:56





ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; Your cert supports TLS1.2?

– mjwills
Nov 16 '18 at 12:56




1




1





Honestly, my suggestion in these cases is to get the cert working.

– mjwills
Nov 16 '18 at 12:57





Honestly, my suggestion in these cases is to get the cert working.

– mjwills
Nov 16 '18 at 12:57













Unrelated: You're using HttpClient wrong and Using HttpClient As It Was Intended (Because You’re Not)

– Fildor
Nov 16 '18 at 13:01





Unrelated: You're using HttpClient wrong and Using HttpClient As It Was Intended (Because You’re Not)

– Fildor
Nov 16 '18 at 13:01













@Fildor I am aware of that - it's only an example :)

– finlaybob
Nov 16 '18 at 13:03





@Fildor I am aware of that - it's only an example :)

– finlaybob
Nov 16 '18 at 13:03












1 Answer
1






active

oldest

votes


















0














I was looking completely in the wrong place. The problem lay in the IIS setup.



The site binding was for some reason explicitly set to 10.0.0.21:433. Switching this to "All Unassigned" - seems to have made this work.



I am probably out of my depth, and could be wrong, but I suspect the reason for this is that according to Wireshark, the response to the MDNS request to find the hostname IP, was returning the ipv6 address of the server machine, which of course isn't 10.0.0.21. Again, I could be wrong.



The reason I am so unsure is that chrome seems to have ploughed right through and found the correct thing when I put in https://test-machine/api/Example and I cannot explain why.






share|improve this answer
























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53338316%2fhttpclient-https-request-fails-using-hostname-but-works-using-ip-address%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    I was looking completely in the wrong place. The problem lay in the IIS setup.



    The site binding was for some reason explicitly set to 10.0.0.21:433. Switching this to "All Unassigned" - seems to have made this work.



    I am probably out of my depth, and could be wrong, but I suspect the reason for this is that according to Wireshark, the response to the MDNS request to find the hostname IP, was returning the ipv6 address of the server machine, which of course isn't 10.0.0.21. Again, I could be wrong.



    The reason I am so unsure is that chrome seems to have ploughed right through and found the correct thing when I put in https://test-machine/api/Example and I cannot explain why.






    share|improve this answer




























      0














      I was looking completely in the wrong place. The problem lay in the IIS setup.



      The site binding was for some reason explicitly set to 10.0.0.21:433. Switching this to "All Unassigned" - seems to have made this work.



      I am probably out of my depth, and could be wrong, but I suspect the reason for this is that according to Wireshark, the response to the MDNS request to find the hostname IP, was returning the ipv6 address of the server machine, which of course isn't 10.0.0.21. Again, I could be wrong.



      The reason I am so unsure is that chrome seems to have ploughed right through and found the correct thing when I put in https://test-machine/api/Example and I cannot explain why.






      share|improve this answer


























        0












        0








        0







        I was looking completely in the wrong place. The problem lay in the IIS setup.



        The site binding was for some reason explicitly set to 10.0.0.21:433. Switching this to "All Unassigned" - seems to have made this work.



        I am probably out of my depth, and could be wrong, but I suspect the reason for this is that according to Wireshark, the response to the MDNS request to find the hostname IP, was returning the ipv6 address of the server machine, which of course isn't 10.0.0.21. Again, I could be wrong.



        The reason I am so unsure is that chrome seems to have ploughed right through and found the correct thing when I put in https://test-machine/api/Example and I cannot explain why.






        share|improve this answer













        I was looking completely in the wrong place. The problem lay in the IIS setup.



        The site binding was for some reason explicitly set to 10.0.0.21:433. Switching this to "All Unassigned" - seems to have made this work.



        I am probably out of my depth, and could be wrong, but I suspect the reason for this is that according to Wireshark, the response to the MDNS request to find the hostname IP, was returning the ipv6 address of the server machine, which of course isn't 10.0.0.21. Again, I could be wrong.



        The reason I am so unsure is that chrome seems to have ploughed right through and found the correct thing when I put in https://test-machine/api/Example and I cannot explain why.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 16 '18 at 15:53









        finlaybobfinlaybob

        530825




        530825
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53338316%2fhttpclient-https-request-fails-using-hostname-but-works-using-ip-address%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Bressuire

            Vorschmack

            Quarantine