You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID> on 2017/09/01 15:55:47 UTC
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Hello,
I am getting an error ERR_SSL_VERSION_OR_CIPHER_MISMATCH on one of my Solr servers. The details show that it's an Unsupported protocol: The client and server don't support a common SSL protocol version or cipher suite. I have changed my browser settings and nothing seems to work. If I comment out the SSL configuration in the solr.in.sh and use HTTP the site Admin site comes up fine. I have searched for where the ciphers might be but, I am unsuccessful as I am not sure that they are the ciphers in TOMCAT or do they get written somewhere else? I've gone over the certs several times I have compared it to a working Solr server and nothing seems different. Other than this one does not work.
Thank you,
Kent
Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Posted by "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID>.
Sorry I am not using Tomcat. This is a fresh build of solr.
Sent from my iPhone
> On Sep 1, 2017, at 3:33 PM, Rick Leir <rl...@leirtech.com> wrote:
>
> Kent,
> Did you say you are using Tomcat? Solr does not use Tomcat by default, so you will need to tell us more about your configuration.
>
> But first, think of what you might have changed just before it stopped working.
> Cheers -- Rick
>
>> On September 1, 2017 11:55:47 AM EDT, "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID> wrote:
>>
>> Hello,
>>
>> I am getting an error ERR_SSL_VERSION_OR_CIPHER_MISMATCH on one of my
>> Solr servers. The details show that it's an Unsupported protocol:
>> The client and server don't support a common SSL protocol version or
>> cipher suite. I have changed my browser settings and nothing seems to
>> work. If I comment out the SSL configuration in the solr.in.sh and use
>> HTTP the site Admin site comes up fine. I have searched for where the
>> ciphers might be but, I am unsuccessful as I am not sure that they are
>> the ciphers in TOMCAT or do they get written somewhere else? I've gone
>> over the certs several times I have compared it to a working Solr
>> server and nothing seems different. Other than this one does not work.
>>
>>
>>
>>
>>
>>
>> Thank you,
>>
>> Kent
>
> --
> Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Posted by Rick Leir <rl...@leirtech.com>.
Kent,
Did you say you are using Tomcat? Solr does not use Tomcat by default, so you will need to tell us more about your configuration.
But first, think of what you might have changed just before it stopped working.
Cheers -- Rick
On September 1, 2017 11:55:47 AM EDT, "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID> wrote:
>
>Hello,
>
>I am getting an error ERR_SSL_VERSION_OR_CIPHER_MISMATCH on one of my
>Solr servers. The details show that it's an Unsupported protocol:
>The client and server don't support a common SSL protocol version or
>cipher suite. I have changed my browser settings and nothing seems to
>work. If I comment out the SSL configuration in the solr.in.sh and use
>HTTP the site Admin site comes up fine. I have searched for where the
>ciphers might be but, I am unsuccessful as I am not sure that they are
>the ciphers in TOMCAT or do they get written somewhere else? I've gone
>over the certs several times I have compared it to a working Solr
>server and nothing seems different. Other than this one does not work.
>
>
>
>
>
>
>Thank you,
>
>Kent
--
Sorry for being brief. Alternate email is rickleir at yahoo dot com
RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Posted by "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID>.
The java.security files are the same. I even copied over the files from a machine that is working and renamed the security files and it still did not work.. I am getting the same error.
-----Original Message-----
From: Younge, Kent A - Norman, OK - Contractor [mailto:Kent.A.Younge@usps.gov.INVALID]
Sent: Tuesday, September 05, 2017 6:54 AM
To: solr-user@lucene.apache.org
Subject: RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The new box is a clone of all the boxes so nothing should have changed other than the certificates and the keystore. That is why I am at such a loss on this issue. Java is the same across five servers all settings are the same across five servers. I will look into the JVM security and see if it is the same across all the boxes.
-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
Sent: Friday, September 01, 2017 5:46 PM
To: solr-user@lucene.apache.org
Subject: Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
all of the low level SSL code used by Solr comes from the JVM.
double check which version of java you are using and make sure it's consistent on all of your servers -- if you disable SSL on the affected server you can use the Solr Admin UI to be 100% certain of exactly which version of java is being used...
https://lucene.apache.org/solr/guide/6_6/overview-of-the-solr-admin-ui.html
If the JVM Runtime *versions* are identicle, the next thing to check would be the the JVM security settings which control which ciphers are used.
For Oracle JVMs this file is named "java.security" -- compare that file between your functional/non-functional servers.
There are lots of docs out there on SSL protocol and cipher configuration in java's java.security file, here's a quick one that links deep into the details of enabling/disabling protocols...
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols
...but the bottomline is: you probably want to fix your broken server to match your working servers, and unless the JVM versions are different, that means someone/thing must have modified the JVM security settings on one of your servers -- find out who & why.
-Hoss
http://www.lucidworks.com/
RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Posted by "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID>.
New Solr Box built Getting Cipher mismatch. Where are the Solr Java Cipher's located?
-----Original Message-----
From: Younge, Kent A - Norman, OK - Contractor [mailto:Kent.A.Younge@usps.gov.INVALID]
Sent: Thursday, September 07, 2017 6:42 AM
To: solr-user@lucene.apache.org
Subject: RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Still receiving the same issue. I have cloned another machine and it has the same issue. Not sure what to do next. Last resort build machine from scratch and see if it has the same issue if it does then I have no clue what is going on.
-----Original Message-----
From: Younge, Kent A - Norman, OK - Contractor [mailto:Kent.A.Younge@usps.gov.INVALID]
Sent: Tuesday, September 05, 2017 6:54 AM
To: solr-user@lucene.apache.org
Subject: RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The new box is a clone of all the boxes so nothing should have changed other than the certificates and the keystore. That is why I am at such a loss on this issue. Java is the same across five servers all settings are the same across five servers. I will look into the JVM security and see if it is the same across all the boxes.
-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
Sent: Friday, September 01, 2017 5:46 PM
To: solr-user@lucene.apache.org
Subject: Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
all of the low level SSL code used by Solr comes from the JVM.
double check which version of java you are using and make sure it's consistent on all of your servers -- if you disable SSL on the affected server you can use the Solr Admin UI to be 100% certain of exactly which version of java is being used...
https://lucene.apache.org/solr/guide/6_6/overview-of-the-solr-admin-ui.html
If the JVM Runtime *versions* are identicle, the next thing to check would be the the JVM security settings which control which ciphers are used.
For Oracle JVMs this file is named "java.security" -- compare that file between your functional/non-functional servers.
There are lots of docs out there on SSL protocol and cipher configuration in java's java.security file, here's a quick one that links deep into the details of enabling/disabling protocols...
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols
...but the bottomline is: you probably want to fix your broken server to match your working servers, and unless the JVM versions are different, that means someone/thing must have modified the JVM security settings on one of your servers -- find out who & why.
-Hoss
http://www.lucidworks.com/
RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Posted by "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID>.
Still receiving the same issue. I have cloned another machine and it has the same issue. Not sure what to do next. Last resort build machine from scratch and see if it has the same issue if it does then I have no clue what is going on.
-----Original Message-----
From: Younge, Kent A - Norman, OK - Contractor [mailto:Kent.A.Younge@usps.gov.INVALID]
Sent: Tuesday, September 05, 2017 6:54 AM
To: solr-user@lucene.apache.org
Subject: RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The new box is a clone of all the boxes so nothing should have changed other than the certificates and the keystore. That is why I am at such a loss on this issue. Java is the same across five servers all settings are the same across five servers. I will look into the JVM security and see if it is the same across all the boxes.
-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
Sent: Friday, September 01, 2017 5:46 PM
To: solr-user@lucene.apache.org
Subject: Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
all of the low level SSL code used by Solr comes from the JVM.
double check which version of java you are using and make sure it's consistent on all of your servers -- if you disable SSL on the affected server you can use the Solr Admin UI to be 100% certain of exactly which version of java is being used...
https://lucene.apache.org/solr/guide/6_6/overview-of-the-solr-admin-ui.html
If the JVM Runtime *versions* are identicle, the next thing to check would be the the JVM security settings which control which ciphers are used.
For Oracle JVMs this file is named "java.security" -- compare that file between your functional/non-functional servers.
There are lots of docs out there on SSL protocol and cipher configuration in java's java.security file, here's a quick one that links deep into the details of enabling/disabling protocols...
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols
...but the bottomline is: you probably want to fix your broken server to match your working servers, and unless the JVM versions are different, that means someone/thing must have modified the JVM security settings on one of your servers -- find out who & why.
-Hoss
http://www.lucidworks.com/
RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Posted by "Younge, Kent A - Norman, OK - Contractor" <Ke...@usps.gov.INVALID>.
The new box is a clone of all the boxes so nothing should have changed other than the certificates and the keystore. That is why I am at such a loss on this issue. Java is the same across five servers all settings are the same across five servers. I will look into the JVM security and see if it is the same across all the boxes.
Thank you,
Kent Younge
Systems Engineer
USPS MTSC IT Support
600 W. Rock Creek Rd, Norman, OK 73069-8357
O:405 573 2273
-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
Sent: Friday, September 01, 2017 5:46 PM
To: solr-user@lucene.apache.org
Subject: Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
all of the low level SSL code used by Solr comes from the JVM.
double check which version of java you are using and make sure it's consistent on all of your servers -- if you disable SSL on the affected server you can use the Solr Admin UI to be 100% certain of exactly which version of java is being used...
https://lucene.apache.org/solr/guide/6_6/overview-of-the-solr-admin-ui.html
If the JVM Runtime *versions* are identicle, the next thing to check would be the the JVM security settings which control which ciphers are used.
For Oracle JVMs this file is named "java.security" -- compare that file between your functional/non-functional servers.
There are lots of docs out there on SSL protocol and cipher configuration in java's java.security file, here's a quick one that links deep into the details of enabling/disabling protocols...
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols
...but the bottomline is: you probably want to fix your broken server to match your working servers, and unless the JVM versions are different, that means someone/thing must have modified the JVM security settings on one of your servers -- find out who & why.
-Hoss
http://www.lucidworks.com/
Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Posted by Chris Hostetter <ho...@fucit.org>.
all of the low level SSL code used by Solr comes from the JVM.
double check which version of java you are using and make sure it's
consistent on all of your servers -- if you disable SSL on the affected
server you can use the Solr Admin UI to be 100% certain of exactly which
version of java is being used...
https://lucene.apache.org/solr/guide/6_6/overview-of-the-solr-admin-ui.html
If the JVM Runtime *versions* are identicle, the next thing to check would
be the the JVM security settings which control which ciphers are used.
For Oracle JVMs this file is named "java.security" -- compare that file
between your functional/non-functional servers.
There are lots of docs out there on SSL protocol and cipher configuration
in java's java.security file, here's a quick one that links deep into the
details of enabling/disabling protocols...
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols
...but the bottomline is: you probably want to fix your broken server to
match your working servers, and unless the JVM versions are different,
that means someone/thing must have modified the JVM security settings on
one of your servers -- find out who & why.
-Hoss
http://www.lucidworks.com/