updated to Version 70.0.3538.35 (Official Build) beta (64-bit)
I changed the dns "A" record per heroku's old instructions so that all requests (http , https ) to my site would reroute in Heroku front=end to my $herokuapp.1234 domain. it just broke.
and a site no longer renders without the ssl warnings :
In the past , i just let Heroku's front end handle the SSL requests , routing them to my app but as of today , in chrome that does not work anymore..
have looked here but not sure what to do?
Some months ago I switched everything over the the free certificates provided by Heroku's ACM and haven't looked back - free, automatic, easy - so unless you have a compelling reason to be using the legacy infrastructure I'd suggest make the switch.
As Heroku says (at that link you posted):
New Heroku applications should use Heroku SSL, which includes Automated Certificate Management (ACM). The SSL Endpoint add-on described in this article is only recommended for supporting legacy Heroku applications, or for applications that require custom security policies.
Related
I've a locally hosted SPA (Kestral/.Net core). It is using a self signed certificate for HTTPS communication (generated through Server Certificates in windows 10).
It works well with IE11, however when accessed from Google Chrome, shows up error - ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY.
Any clues on what could be done to overcome this?
Troubleshooting done so far:
Custom cipher suites order.
Disabling HTTP2 through windows registry.
To use HTTP/2 you must be using TLSv1.2 and cannot use a number of blacklisted, less secure ciphers. This basically means you must use one of the GCM ciphers like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (though other newer ciphers like TLS_CHACHA20_POLY1305_SHA256 are also support).
If you only have older ciphers configured then Chrome will fallback to HTTP/1.1 or, if that is not available, it will error with that error message.
Adding if it helps anyone digging on same thing, for Kestral setting Protocol Version to http1 looks to be the way to overcome this issue, as Cipher suite doesn't looks to be configurable in kestral at least with .Net core 3.1.
So this is kind of odd.
My scenario:
Web server running IIS, hosting asp.net applications
SQL server
As they are on separate servers, I had to set up kerberos delegation. I have got this working.
So a user goes to asp.net application hosted on the web server, and it authenticates them to the SQL server.
On one of my web apps, when they go to it in Chrome, I get the error page with SQL authentication failed due to Anonymous user. If they go to the same app in IE, it works correctly.
Here is the really odd part - if they then go to it again in Chrome, it works!
So I guess there is some inconsistency in how Chrome authenticates.
I found someone suggesting it might be to do with the IIS negotiation providers, but as it needs kerberos delegation I have to have "Negotiate" as the first option or it fails completely.
I guess I could just tell users they have to use IE, but I would prefer to get it to work in Chrome.
Any thoughts?
(Possibly similar to Kerberos not working with Chrome but it's all on intranet zone, so don't think there's anything to whitelist)
Installed some updates on Ubuntu and now Chrome is prefixing all of my local development sites with https. I haven't got any certificates installed so Apache is refusing to connect and I'm getting this error message:
This site can’t be reached
xyz.dev refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED
I'm using Chrome 63.0.3239.84 on Ubuntu 16.04
The sites work in Firefox 57.0.1 so its a Chrome specific thing.
How do I switch this off in Chrome?
You can’t switch it off. Google has bought the .dev TLD, so now they think they can do what they think is best with it.
https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts has more info on the whole issue.
Switch to another extension for local development (I usually prefer .local - hope they don’t get their grubby little fingers on that one at some point, too, LOL), or install at least a self-signed certificate in your Apache.
We're using Jetty 9.2.x in the embedded mode in conjunction with Restlet 2.3.1 to develop our application sever. Recently we've enabled support for HTTPS, which utilises a certificated signed by a self-established CA.
Everything seemed to be working correctly when connecting to this server from various web browsers under Linux and Mac operating systems. However, when we expended out testing to machines running Windows 7 and 8 (all machines are on the same LAN), we've discovered that the Chrome browser (ver. 42.x) would not establish a connection, reporting
This web page is not available
ERR_FAILED
The webpage at https://host_name:9999/ might be temporarily down or it may have moved permanently to a new web address.
Trying to analyse TCP/IP messages between the browser and the server suggests that HTTPS handshake does not succeed. Surprisingly, everything works correctly under Windows XP.
Unfortunately, we're not sure how to proceed any further in trying to solve this problem. Any suggestions as to a possible cause or a solution to the described situation?
It has also beed observed that Firefox under Windows 7/8 was able to establish the connection, but did not render the page due to lack of HTML5 imports support. This was confirmed by observing the page source from Firefox.
Edit: Configuring Jetty to use a self-signed certificate resolved the connectivity problem. This suggests that there is some issue with signing a certificate by a self-established CA, which seems to be specific to an operating system/web browser combination.
It has been identified that the originally used certificate was at fault. More specifically, its Common Name contained a value, which was not recognised as a suitable domain name. Generating a new certificate, signed with a self-established CA, but providing a suitable (albeit not registered) domain name in property Common Name has solved the problem.
The very original intent for thus issued certificate was to use it for internal development purposes and not for public consumption. Thus, the Common Name property was entered to reflect the local nature of the certificate (e.g. application-name.local).
Since I have updated Chrome from Version 40 to 41, I no longer can access my ssl site running in a local tomcat 7 instance. I have a self signed certificate.
Chrome just prints This webpage is not available together with ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
I already tried the chrome://flags switch Minimum SSL/TLS version supported to SSLv3, which did not work.
I had the same problem with my Java EE web application running with a self signed certificate on Wildfly 8.1.
You are probably using a 1024 bit DSA public key with your selfsigned certificate and Chrome stops/stopped supporting DSA(DSS).
Creating a RSA 2048 certificate and using it with your web application should solve your problem.
I doubt its an SSL/TLS protocol version problem. Most of the time this error means the server and client couldn't agree on which cipher to use. Take a look at this blog post: https://blog.eveoh.nl/2014/02/tls-ssl-ciphers-pfs-tomcat/ on how to enable a secure and compatible cipher suite in Tomcat.
In the Tomcat server.xml file you can set ciphers attribute in the SSL/TLS <connector/> element.
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_RC4_128_SHA"
This solved the problem in my case for ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chromium / Chrome and for ssl_error_no_cypher_overlap in Firefox.
If you came here from Google and since this is the highest ranking 'ERR_SSL_VERSION_OR_CIPHER_MISMATCH' entry:
another explanation is that you started an nodejs https or express server with invalid or empty credentials. The irritating bit is that the server starts without complaining and ssl seems to work, but the negotiation between browser and server fails with this error.