We are usng Weblogic 8.1 and administration console suddenly stopped and inaccessible today.
For more than a year we use to access it until today as it is being blocked by these browsers:
Internet Explorer -
There is a problem with this website's security certificate. When i click continue, it's not redirecting to the admin console.
Google Chrome - SSL server probably obsolete.
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION
Firefox - Secure Connection Failed
An error occurred during a connection to 192.168.0.18:17050. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
You are running a very old version of JRocket Java equivalent to 1.4.
There is a SSL protocol mismatch between your modern browsers and Weblogic's JRocket.
My best guess is to install the JRocket Java Cryptography Extension (JCE) Unlimited Strength files into your JRocket to boost the cipher list.
nmap has a ssl-enum-ciphers that will be able to print out the list of ciphers avialable before and after you install the Unlimited Strength files. See answer.
As an alternative and very ugly solution in Firefox.
Try this.
Enable support for 40-bit RSA encryption in the Firefox Browser:
enter 'about:config' in Browser Address bar
find/select
"security.ssl3.rsa_rc4_40_md5" set boolean to TRUE
Or this.
Open a new tab in Firefox and type “about:config” in the URL bar
You would get a warning dialog box, click Promise to be careful and move on
In the search bar, enter the following security.tls.version
First, right-click on the setting “security.tls.version.fallback-limit” and select modify. You’re going to change the “1” to “0”. Then do the same thing with “security.tls.version.min”, changing the “1” to “0”.
Related
I have a few VS 2019 projects that some colleagues created and that I downloaded and attempted to run. Straight out of the box with no modification, Chrome and Firefox both complain (Edge does not.)
I am running this using Kestrel, by the way.
Chrome:
"This site can’t be reached
The webpage at https://localhost:5001/ might be temporarily down or it may have moved permanently to a new web address.
ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY"
Firefox
Your connection is not secure... blah blah...
NS_ERROR_NET_INADEQUATE_SECURITY
I have used the workaround in appsettings.json:
"Kestrel": {
"EndpointDefaults": {
"Protocols": "Http1"
}
However, simply regressing to Http1 isn't a solution, it's just a workaround. I'm also not sure why my colleagues are not experiencing this problem, and I am not. Any ideas would be greatly appreciated.
Check your TLS setup as HTTP/2 blacklists most older, more insecure ciphers as listed in the specification and may not allow the connection to use HTTP/2 if they are used. You should configure your web server to use more modern GCM ciphers like TLS_AES_256_GCM_SHA384.
I have enabled SSL for a site using jdk 1.8 and Tomcat 8.5.23.
When I hit the site in IE, first time it shows:
"Can't connect securely to this page
This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening,try contacting website's owner."
When I hit the site second time, the page loads and the application functionality works fine with SSL enabled.
When I hit the site in chrome no matter how many times, it shows:
"This site can't provide a secure connection
Abcd.xyz.com didn't accept your login certificate, or one may not have been provided.
Try contacting the system admin.
ERR_BAD_SSL_CLIENT_AUTH_CERT"
In server.xml I have added below in the connector tag:
SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"
I also could not find any error in the log files.
Please help me. :(
I can’t run local testing(for example http://localhost:3000) on browserstack.
I'm using Linux Mint 18.3 Sylvia x64. Browser is Chromium.
The browser’s extension (app) is installed.
The screenshot shows that there is no connection.
http://joxi.ru/Y2LJBv0H9MBv8r
The checkbox is checked.
http://joxi.ru/1A5PvVpCnzMww2
I tried this manual https://www.browserstack.com/local-testing.
./BrowserStackLocal --key
The above command is started, but nothing happened.
BrowserStack's Support Answer:
Thank you for joining the screen share session. As per our investigation, it seems that few of the IP's of our servers hosted on AWS are blocked due to Telegram blockage by Roskomnadzor which is leading towards the issue.
Having said that, our team is evaluating alternate solutions for our Russian users and I will be sure to notify you of the developments.
Cool!
But my neighbour doesn't have problems, he has Windows.
We have a common Internet provider.
Try replacing 'localhost' in the URL you are using with the IP address of the machine. For example, if you are testing the URL "http://localhost:3000/index.html" try using http://<machine_ip_address>:3000/index.html instead.
We've started encountering issues browsing to most https sites.
Examples include: https://technet.microsoft.com/, https://mail.google.com/, https://www.mozilla.org/en-US/firefox/new/, https://stackoverflow.com/
It appears that secure sites that we have visited previously work OK. Examples of these include:
https://banking.westpac.com.au/, https://www.tppwholesale.com.au/login/, https://au.ingrammicro.com/
The errors we receive are:
Chrome: ERR_BAD_SSL_CLIENT_AUTH_CERT
Firefox: SSL_ERROR_ACCESS_DENIED_ALERT
IE11/Edge: No helpful message, but Schannel 36887 errors are logged advising The TLS protocol defined fatal alert code is 49. (These are also logged for Chrome, but not Firefox as it uses the Mozilla NSS encryption library.)
We can prevent the problem by disabling TLS1.1 & TLS1.2 and enabling SSL2 & SSL3. As SSL2/3 have known vulnerabilities we want to resolve this issue properly.
Problem has been observed on Win7, Win8.1, Win10 WS2012R2 machines. It's affecting all our laptop computers except one that hasn't been in the office for over a month.
Extensive googling has failed to yield anything helpful - most SSL connection issues that are discussed seem to focus on the server certificate.
The above errors suggest it being an issue with the client certificate that our browsers are sending to the servers, so I have these questions:
Do SSL2/3 have different client certificate requirements to TLS1.x?
What client certificate do browsers use (we don't have any certificates listed in the user or computer Personal stores)?
I hope there's an SSL/TLS guru out there that can assist!
No need to uninstall ESET. Open ESET > Setup > Internet Protection > edit "Web Access Protection" > expand "Web Protocols" > disable "Enable HTTPS Checking".
It appears that ESET antivirus is the culprit here. Thanks to Nicolas Rey for flagging this on a Chrome forum (refer https://productforums.google.com/forum/#!msg/chrome/WHw6ow1kGUs/MW3gt1hZEQAJ)
The rollback option that Nicolas suggested didn't help, but uninstalling and reinstalling ESET resolved the issue.
In Eset go to advanced setup. Then click WEB AND EMAIL, Expand SSL/TLS. Click on edit in List of known certificates. Change access to allow or remove sites from here.
In Eset no need to Disable "Enable HTTPS Checking" . In Web access Protection click URL Management> Click Edit on address list then add on list of allowed addresses
I'm setting up Apache on Centos the way I have done in the past, but for some reason mod_spdy is not running. I'm following the instructions here:
https://developers.google.com/speed/spdy/mod_spdy/
When I run rpm -U mod-spdy-beta_current_x86_64.rpm I get this message:
warning: mod-spdy-beta_current_x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
package mod-spdy-beta-0.9.4.3-420.x86_64 is already installed
If I open chrome://net-internals/#spdy and my site in another tab, it doesn't show my site. If I look in the network panel, I don't see the x-mod-spdy header.
Update: If I use Firefox firebug, I see the x-mod-spdy header. I don't see my site in Chrome spdy sessions, but I see other sites in it.
What could I be doing wrong?
Ok it seems the issue is that Chrome 40.x dropped support for SPDY/3 and only supports SPDY/3.1, but the mod_spdy module for Apache only supports SPDY/3, so basically no SPDY for Chrome users if you use Apache as a web server.
mod_spdy is currently in a bad state where either Google nor Apache is maintaining it after Google donated it to the Asf. Google recently made the statement that they will drop the SPDY support from Chrome in early 2016, but what they forgot to say that they started dropping older versions of SPDY already (including SPDY/3) (I like these partially true statements by the way), so basically if you are on Apache then for your Chrome users you can't provide SPDY short of implementing SPDY/3.1 yourself.
So, how was that "do no evil"? :-)
See details: https://groups.google.com/forum/#!topic/mod-spdy-discuss/FPEj0zG5I0Y
and https://code.google.com/p/mod-spdy/issues/detail?id=100&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20Stars
One option you might consider is switching to Nginx and using SPDY/3.1 over there.