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;
}
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.
- HttpRequestException: An error occurred while sending the request.
- WebException: The underlying connection was closed: An unexpected error occurred on a send.
- IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
- 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
|
show 3 more comments
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.
- HttpRequestException: An error occurred while sending the request.
- WebException: The underlying connection was closed: An unexpected error occurred on a send.
- IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
- 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
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
|
show 3 more comments
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.
- HttpRequestException: An error occurred while sending the request.
- WebException: The underlying connection was closed: An unexpected error occurred on a send.
- IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
- 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
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.
- HttpRequestException: An error occurred while sending the request.
- WebException: The underlying connection was closed: An unexpected error occurred on a send.
- IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
- 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
c# https dotnet-httpclient
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
|
show 3 more comments
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
|
show 3 more comments
1 Answer
1
active
oldest
votes
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 16 '18 at 15:53
finlaybobfinlaybob
530825
530825
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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