Fiddler Ideas
The free web debugging proxy for any browser, system or platform.
The free web debugging proxy for any browser, system or platform.
The free web debugging proxy for any browser, system or platform.
Many sites using SNI to support multiple HTTPS web sites via an IP address, when doing host remapping we always get warning of cert mismatch, but actually the remote server have correct cert installed.
If Fiddler can connect remote server with SNI supported when host remapping enabled, then we will not see the false warning of certificate mismatch.
thank you very much
Guest
Sorry for the late response.
Yes, it refer to tools->hosts.
For example, I override fiddler.ideas.aha.io within tools->hosts as below,
52.7.117.222 fiddler.ideas.aha.io
Then I compose a https request and get "Certificate Error" message,
Session #1056: The server (52.7.117.222) presented a certificate that did not validate, because it was issued to a different host.
SANs: *.aha.io, aha.io
SUBJECT: CN=*.aha.io, OU=PremiumSSL Wildcard, O=Aha Labs Inc., L=Menlo Park, S=CA, PostalCode=94025, C=US
This warning can be disabled by clicking Tools > Telerik Fiddler Options.
Actually, 52.7.117.222 is the real IP of fiddler.ideas.aha.io, it can be access directly from browser, but when overriding DNS by tools->hosts, it get cert error.
I thought it should be caused by not sending correct servername during https SNI connection with remote server.
Can you be specific about what "warning of cert mismatch" you're referring to (a screenshot would be great)?
Fiddler's HOSTS extension sets X-IgnoreCertCNMismatch on all modifications so it shouldn't ever complain about name mismatches.
In terms of what gets sent via SNI:
The SNI sent to the server is the hostname value passed in the SslStream's AuthenticateAsClient call. The hostname comes from the Host header on the request, or the X-OverrideCertCN flag on the request.
Both the ApplyRewrite and the ApplyReroute functions in the HostsFile extension set X-overrideCertCN to the hostname of the original request, not the hostname to which the request was rewritten or rerouted. I think this is probably the right thing to do for the ApplyReroute function (as the SNI continues to match the HOST header on the request) but probably NOT the right thing to do for the ApplyRewrite call because that will mean that the Host header and the sent SNI will not match; some servers like Cloudflare will refuse to serve content in this case.
When you say "Host remapping enabled" do you mean that you're using the TOOLS > HOSTS feature? If so, can you share one or more instances of the rules?
(Does the rule you're using include a third token of rewrite or reroute?)