So I chose to use Cloudflare's shared SSL certificate with CDN, now the website I sign up for has this certificate shown in the browser:
The "issued to" domain is not my domain, this caused a problem:
The https post API of my program thinks my website does not have a valid certificate
However, when I open up my site with Chrome browser, the secured icon shows up:
It seems that the browser thinks the Cloudflare shared certificate is OK,
while the "issued to" domain is clearly not my domain
So the question is:
Why does the browser trust the shared SSL certificate with "issued to" not matching my domain, while the WebRequest from a C# program does not trust?
Turns out there is a "Subject Alternate Names" field in the certificate details, which allows browsers to trust certificate with non "issued to" domain, big thanks to #SLaks.
The reason why it didn't work on my C# api access is that Unity does not support ECDH(Elliptic-curve Diffie–Hellman) for HTTPS, and Cloudflare only supports ECDH.
So, the HTTPS api to my server through Cloudflare is working for Chrome, but not working for Unity. I searched around and found it does not work for some versions of Monodevelop lineup and Xiamarin as well.
Bug
Related
I'm trying to set up Cookie Authentication in Blazor WebAssembly, running in Chrome.
WebApp runs on https://localhost:44342
WebApi runs on https://localhost:44377
After a post request (with PostAsJsonAsync) to https://localhost:44377/user/loginuser with valid credentials, the WebApi sends back a response header with Set-Cookie: .AspNetCore.Cookies=...
That cookie seems to be rejected by the browser, because
I don't see it in F12 -> Application -> Cookies
Subsequent requests don't have the cookie attached
I researched the problem on the net extensively. I found loads of hints and explanations. Including configuring CORS, using the IP instead of localhost, setting cookie properties like SameSite, HttpOnly, Expiration and Domain or using chrome internals for further investigation.
None of that helped. Set-Cookie is still ignored by the browser.
Does anyone have a good idea on how I could proceed? Thanks
I had probably the same problem.
Chrome browser is denying the cookie ‘couse the domain is not using SSL and the cookie policy uses samesite:none.
I solved using a certificate in IIS (using HTTPS instead of HTTP). I had this problem only in production. For the development environment, when you create the project, visual studio asks if you want register a development certificate. Check yes.
I started to use Fiddler and I want to be able use it to debug https requests.
I read the part "Configuring for HTTPS Capture" in the
following article: http://www.kleinfelter.com/content/using-fiddler-capture-encrypted-traffic-https
So I decided to change the properties of Fiddler to enable also https requests. I checked both "Capture HTTPS CONNECTs" and "Decrypt HTTPS traffic"
Once I clicked the "OK" button my browser blocked any https requests. Therefore, I couldn't enter any sites with personal information such as Facebook or Gmail. The error message that I got from the browser was:
Your connection is not private
Attackers might be trying to steal your information from
www.facebook.com (for example, passwords, messages, or credit cards).
NET::ERR_CERT_AUTHORITY_INVALID
I probably have to change something in the properties of my browser (Chrome) so I'll be able to submit https requests while fiddler is working. I know it may be unsecure, but once I finish using Fiddler, I'll change it back to its default property.
Do you know what I have to change in my browser?
Fiddler uses its own root CA when acting as a MITM proxy to decrypt HTTPS traffic. This CA is not trusted by Windows (which is good, as Fiddler does not have the authority to issue certificates). Fiddler uses this root CA to create certificates on the fly for HTTPS sites you visit enabling it to decrypt content.
The message you are seeing is Chrome warning you that the issuer of the dynamically Fiddler generated certificate is unknown. On most sites, you can bypass this by accepting the warning but some sites employ additional security practices such as Strict Transport Security (HSTS) and certificate pinning where a browser prohibits you from accepting warnings such as these.
To avoid having browsers show a warning, you should add the Fiddler root certificate to your trusted certificates. IE and Chrome share the same certificate store maintained in Windows, while Firefox maintains its own store internally.
To trust Fiddler's Root certificate,
Click the "Export Root Certificate to Desktop" button in your screen print (in newer versios, this is available behind a button titled "Action" on the same dialog).
This exports the Fiddler root certificate to your desktop.
Open the certificate file and click the "Install Certificate" button.
Proceed with the rest of the prompts to add it to your list of trusted root certificates.
References: https://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp and http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/TrustFiddlerRootCert
I'm using Fiddler2 on Windows to inspect and analyze HTTPS traffic. To make it less cumbersome, I've installed and trusted the Fiddler2 Root certificate. The Fiddler root certificate makes the browsing experience seamless; all the HTTPS sites are still "secured" (ie: the url is still https, and you still see a certificate lock).
But this becomes problematic when I forget to turn off Fiddler, and find myself browsing sites that I want to remain secured, only to find Fiddler still logging my traffic/content.
Is there a Chrome extension that I can install/use that would visible show when the HTTPS connection is secured by a certificate signed by a specific root?
Unfortunately, it doesn't look like such information is available in the chrome.webRequest API, which you would need to get it in a Chrome Extension.
There was previously a request to Provide information about the TLS connections to extensions via the webRequest API, but it was decided not to be implemented.
Is there any reason why a file may load over http but not over https?
I am curious because I just enabled ssl on a subdomain and it does not seem to be properly. I can see the green lock but if i load the site with it, i see no files.
Like if I have a file at
http://site.exmpl.org/file.html
when i go to
https://site.exmpl.org/file.html
it does not load.
I have ssl enabled because i have the green lock, also i am using cloudflare if that helps
I assume that you may have your SSL mode configured to "Full" in the CloudFlare Crypto section- But lack a ssl certificate installation on your subdomain.
--If not--
You may not have SNI or a Dedicated IP setup for your website then your apache server is likely using your certificate, but connecting to the web space of whoever first setup a SSL Certificate on that server. This is often a problem on shared web hosting environment. You can attempt to contact your provider to ask for help in getting SNI properly configured. You can also acquire a Dedicated IP from your provider.
in cloudflare dashboard under SSL/TLS section go to Edge Certificate instead of overview.
In Edge Certificate there is option called "Always Use HTTPS" which explains "Redirect all requests with scheme “http” to “https”. This applies to all http requests to the zone." just turn in on and after sometimes you are good to go.
I'm using Advanced REST Client to test external API which requires me to specify
Connection: Keep-Alive. The connection fails (NO RESPONSE) and inspecting Chrome console I noticed Refused to set unsafe header "Connection" followed by net::ERR_INSECURE_RESPONSE
Is there any Chrome settings that allow me to override this? BTW, the API works when I use external tools like APIGee. I've tried Chrome CORS extension (Allow Control Allow Origin) but still unsuccessful.
The issue is that chrome is refusing to load a resource that has an invalid or expired SSL certificate. Even if you could get it to bypass that it would be a bad idea as it would make man in the middle attacks easier in your application.
My suggestion would be (if you trust the server or if it's running locally) to import that certificate to your store so it's trusted in your development environment. If the cert is expired and it's hosted locally look at the documentation on how to change the certificate or to add a self signed one (which you then also would add to your trusted sites)
How to add a self signed very to your store
For Mac
For windows
You'll have to restart chrome for it to see the certs in the store after doing this
Again, be sure you trust these certs origin as they'll be considered trusted as if a legit CA HAD issued them