0

I am trying to configure SSL for our server. Now, I have made sure that the that the crt files password is the same as the keystore(.jks password). However, whenever I import the crt file either as alias tomcat or root(only one of them I can use as there is just one crt file), I get ssl_error_no_cypher_overlap.

I am not able to find any guide to import one certificate which will not complain that it's a self-signed certificate and no ssl_error_no_cypher_overlap error for one certificate.

These are the files I have domainname.ca-bundle, .crt, .csr, .key, .p12, domainname.jks,

THis is the command I gave :

keytool -import -trustcacerts -alias root -file domainname.crt -keyalg RSA -keystore domainaname.jks

Connector :

 <Connector port="443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="200" compression="force"
              compressionMinSize="1024" scheme="https" secure="true" clientAuth="false" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" sslProtocol="TLS" URIEncoding="utf-8"
 compressableMimeType="text/html,text/xml,text/plain,text/css,text/ javascript,application/x-javascript,application/javascript"
               keystoreFile="domain.jks" keystorePass="pass" />

Any help would be nice. Thanks a lot.

We are Borg
  • 5,117
  • 17
  • 102
  • 225
  • Try this answer http://stackoverflow.com/questions/29449966/how-to-fix-ssl-error-no-cypher-overlap-on-a-tomcat-7-server – rpc1 Sep 30 '15 at 13:36
  • @rpc1 : Didnt help. Same error. I have updated the main post with my connector. Kindly have a look. – We are Borg Sep 30 '15 at 13:43
  • http://stackoverflow.com/questions/29449966/how-to-fix-ssl-error-no-cypher-overlap-on-a-tomcat-7-server – rkosegi Oct 01 '15 at 19:17
  • @rkosegi : Like I said in main-post, I have tried many of the existing solutions on SO, including the link you posted. Didn't help.. :-) – We are Borg Oct 02 '15 at 08:12

2 Answers2

0

Meta: this feels like a duplicate but I couldn't easily find a match so ...

SSL/TLS server must have a certificate WITH MATCHING PRIVATE KEY and chain certs if applicable. A single certificate by itself, or even several certificates, is not sufficient. First do 

 keytool -list -v -keystore $d.jks

and look for a PrivateKey entry (NOT a trustedCert entry). If that is present, look at the cert(s) to determine whether they are the certs you want. If they aren't the desired cert(s), but you do have the desired cert(s) in your .crt and bundle files, then describe the contents of your .crt and especially bundle files and we can work out how to use them to fix the .jks. In particular, there are two formats commonly used for single certs and several for CA "bundles"; if you open the files in an editor like notepad or vi and the first line is -----BEGIN something----- followed by a block of almost all letters and digits then ----END same---- and maybe more of the same, post the somethings; if they appear to be all random characters and you have a hex dump tool available post the first 64 bytes at least, or if you have OpenSSL or any other ASN.1 (binary) parser available post the results of that. If there is no privatekey at all, this .jks is useless; discard it and continue.

Your .key file sounds likely to contain a private key, but there are dozens of different formats people label .key and it's very unlikely this file is in a usable format. If the key is not more conveniently in the p12, we can come back to this.

Your .p12 file almost certainly contains the private key and some cert(s), but not necessarily the desired cert(s). (Technically the PKCS#12 standard allows a file with no private key, but all common tools that create PKCS#12 don't ever do that.) To see what you have now, do 

keytool -list -v -keystore $d.jks -storetype pkcs12

If it is what you want, Tomcat (and Java/JSSE) can actually use a pkcs12 directly as a keystore in place of a JKS: just set keystoreFile and keystorePass for it and add keystoreType="pkcs12". Alternatively you can convert the pkcs12 to JKS with

keytool -importkeystore -srckeystore $d.p12 -srcstoretype pkcs12 -destkeystore $d.jks

If .p12 contains the privatekey but the wrong cert(s), there are two approaches:

  • first convert the pkcs12 to JKS as just above, then fix the certs in the JKS; this is now the same case as my first paragraph: JKS contains privatekey but wrong cert(s)

  • if you have or get OpenSSL, use it to "unpack" the pkcs12 into separate privatekey and cert files, replace the wrong cert files with the right ones, and reconstruct a new pkcs12. This puts you back in my fourth paragraph: pkcs12 with correct cert(s) which you can either use or convert to JKS and use that.

dave_thompson_085
  • 34,712
  • 6
  • 50
  • 70
  • Hi my friend, I have given the first commands and the output is in the pastebin at : http://pastebin.com/8AJNhxtr . I didn't start with the third command as I thought the output might shed some light on the issue. Kindly let me know how I should proceed. Thanks a lot. :-) – We are Borg Oct 01 '15 at 07:42
  • @WeareBorg your JKS shows two trustedCert's and no PrivateKey, so it's useless. I assume the second display is your .p12; failure to parse the DER indicates it's either damaged or not .p12 at all. If you're on Unix (or can move the file *as binary* to Unix) do `od -tx1a -N64 $d.p12` and show that. Otherwise if you can get any reasonable kind of hexdump of the first 64 bytes or so, do that. If the first bytes of hexdump are `30 82 x x 02 01 03 30 82 x x 06 09` for any x and you have openssl or any other ASN.1 DER parsing program available, do `openssl asn1parse -inform der -in $d.p12` ... – dave_thompson_085 Oct 02 '15 at 21:09
  • ... or equivalent for another program, remove/redact the large hexdump blobs of the values of the OCTET STRINGS, but keep the structure in terms of offsets, depths, tags/types, and object identifiers, and especially any error messages, and show that. While you're at it, you might as well do the same things (hexdump first 64, and try asn1parse) for the `.key` file in case we need that. – dave_thompson_085 Oct 02 '15 at 21:13
0

I tried your connector properties (made some changes with protocol) 

 <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" maxThreads="200" compression="force"
              compressionMinSize="1024" scheme="https" secure="true" clientAuth="false" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" sslProtocol="TLS" URIEncoding="utf-8"
              compressableMimeType="text/html,text/xml,text/plain,text/css,text/ javascript,application/x-javascript,application/javascript"
               keystoreFile="domainaname.jks" keystorePass="123456"    keystoreType="JKS"
               truststoreFile="domainaname.jks"
                truststoreType="JKS" truststorePass="123456"
               />

Every thing works fine changes:

 protocol="org.apache.coyote.http11.Http11NioProtocol"
 truststoreFile="domainaname.jks"
 truststoreType="JKS" truststorePass="123456"

Did you import private keys in keystore?

keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias myservercert
rpc1
  • 688
  • 10
  • 23