@sentinelvdx
As @Merlin hints at its to do with older methods of encryption.
To See Cipher Suites:
https://browserleaks.com/ssl
If you are unable to cat > out the conf in via SSH from the camera.?
If you are able to revert to using older security protocols from within browser settings via
chrome://flags in the address bar. Search for
TLS using the search bar at the top. The results will include the
TLS 1.3 downgrade hardening options
Disable QUIC Protocol
Chrome has many security settings, and “Experimental QUIC Protocol” can be the cause of the err_ssl_version_or_cipher_mismatch error.
To disable the QUIC protocol in Chrome:
In the address bar type in chrome://flags. In the search bar at the top, enter QUIC. The search results should list “Experimental QUIC protocol.”
Change from Default to Disabled, restart Chrome, and try loading the website again.
Then clear SSL State on system
Clear the SSL State on your Computer.
To clear the SSL state on your computer, go directly to the “Internet Properties” section. The quickest way in Windows 10 is to search for “Internet Properties” or “Internet Options” from the Start menu.
to gain initial access then go back in to regrade with latest certs??
From what I gather there has been a shift away from using DHE in TLS1.3 cypher suites / chains. [See Arbitrary Diffie-Hellman groups:
CVE-2016-0701]
Also there has been complete drop of RC4 stream cipher: [See:
Not secure for use in HTTPS ]
For creating a SSL with v3 extentions
SNI [not to be confused with multi-domain SAN]
See this on
X.509 v3 certificate specifically with
SAN section.
In order to use newer browser APIs you need a HTTPS connection. I wrote down the steps I needed to generate a valid certificate.
medium.com
As a Primer This may help:
The difference between the root certificate, intermediate certificates, and server certificate.
support.dnsimple.com
The Problem:
I am dealing with slightly different (yet similar) issue as this.
As of the latest chrome updates and general move to stronger forms of encryption, as in TLS 1.3 it causes problems for older devices (embedded or otherwise setup to admin GUI over HTTPS being on old versions of SSL certificates,etc)
Changes in the Cipher suite ordering of the ciphers which are used in previous TLS mechinisms have changed (or been found to be insecure and dropped (see above)) which maybe as to why your device is throwing this error.
You may find some helpful information with changes in this read:
HTTP Strict Transport Security (HSTS) and TLS1.3. [
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#description]
I susupect this has a fair bit to do with the transition over to TLS1.3 and dropping of previous cypher suite used in previous TLS Schemes... "RC4" being one such portion of the cypher ring which in TLS1.3 has been done away with.
I generated letsencrypt certificate for my site. I installed a certificate with this command for my subdomain pointed to a different machine sudo ./certbot-auto certonly --standalone --email email@
stackoverflow.com
in comments:
Im using spring boot 1.8 and my machine has Java 9-internal. I added these SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA cyphers it tends to work but it disabled seems to be disabled DHE
and
(1) Oracle j9 does not say 'internal' and does support ECDHE (and other EC), and I'm pretty sure but can't easily check OpenJDK also, so I don't know what you have (2) don't use (any suite including) RC4; it's been seriously weakened by attacks over the past decade or so and officially prohibited since 2015 by RFC7465 (3) yes, if you configure only non-DHE suites, it disables DHE; if you want both DHE (for other clients) and non-DHE (for Chrome) suites configure both of them. To make Chrome somewhat happier, configure at least some (nonDHE) AES+GCM suites (it prefers AEAD over CBC)
How to confirm this is cause of your issue? ..is unknown but based on my own past pains trying to figure this all out I hazard a guess this post should help put you on the right path..
TESTED using following dumb luck.:
Only that in generating SSL certs based on cypher-chains using DHE and then generating certs derrived from my own PKI CA based certs using X509 v3 SNI certs and then cross validating PKI CA derrived from those without using either of DH OR ECDHE Elliptic Curve Diffie-Hellman Ephemeral the problem goes away and I no longer see this error thrown anymore during deployment testing, which makes me confident the OP issue could very well be the same issue I tackled only but a few weeks back. -
I am unsure about how exactly each of the three browsers impliments Standards or put differently which are strict on enforcing standards compliance and which are allowing graceful bypass (for a period) and which are not.
To maybe help Keep It Simple (..and your Sanity) run your testing via one browser initially like Chrome then if it works move over to Edge/FF rinse & repeat.
Tools (& Guides) you may find helpful.
[
XCA v2.4.0 Download:
https://hohnstaedt.de/xca/index.php/download]
XCA Step By Step guide into PKI / CA and Self Cert chaining
[Solution #2]
Solution to your problem (Hopefully!)
https://phoenixnap.com/kb/fix-err-ssl-version-or-cipher-mismatch#ftoc-heading-7
