Develop Reference

Deleted a certificate and inserted new certificate in keystore and getting error SSL version mistmatch

I had integrated a certificate in keystore but had to remove it as domain name was wrong and after that I deleted the certificate using following command:
keytool -delete -alias <alias> -keystore <path of keystore>
Before this web site was opening with giving error of not correct ssl but now after integerating the correct certificate its giving error as follow:
This site can’t provide a secure connection uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Mine is windows server with Tomcat 8

If there is no certificate configured for the server then no cipher can be used which requires a certificate for authentication - which includes every cipher usually configured in server and client. This results in the error message you see. To fix it make sure that you have a valid certificate configured.

QuickFIX/J CA Certificate Validation

I have an application written using QuickFIX/J to connect with Bloomberg Server. Recently Bloomberg added CA certificate validation to their servers and they provide additional CA certificate file for handshaking.
My application connected using SSL and when disable CA certificate validation from Bloomberg side, application successfully connect to server and get the messages. Handshaking failed when enable CA validation.
Below are the steps I tried.
Previously i'm using ImportKey Java class to add certificate and key.
I changed it to add multiple certificates. If need I can post the
Java class.
When I connect to the server using openssl s_client it successfully connects to the server.
Is there anything that needs to be changed on Application level? Configuration? Or is there anything to do in the Java keystore level?
Error message comes when connecting is added below:
20160823-06:04:15, FIX.4.4:XXXX->XXXX, error> (Disconnecting: Socket
exception (/XXXX.XXXX.XXX.XX:20237):
javax.net.ssl.SSLHandshakeException: SSL handshake failed.)
Successfully logged out for sessionId : FIX.4.4:XXXX->XXXX
Any help is appreciated!
The configuration:
[default]
# Settings which apply to all the Sessions.
ConnectionType=initiator
LogonTimeout=86400
ResetOnLogon=Y
UseDataDictionary=Y
MaxLatency=240
#StartTime=00:00:00
#EndTime=00:00:00
#StartTime=02:30:00
#EndTime=12:30:00
StartTime=02:21:00
EndTime=12:21:00
HeartBtInt=30
ReconnectInterval=5
[session]
# Settings specifically for one session
BeginString=FIX.4.4
SocketConnectHost=xxx.xxx.xxx.xxx
SocketUseSSL=Y
SocketKeyStorePassword=importkey
CheckLatency=N
#SendResetSeqNumFlag=Y
# new setups
FileLogHeartbeats=Y
##----- CAPS Configuration ---------##
FileStorePath=/etc/bloomburg-live/msgs
FileLogPath=/etc/bloomburg-live/logs
DataDictionary=/etc/bloomburg-live/conf/FIX44.xml
SocketKeyStore=/root/.keystore
TargetCompID=BLPSTP
SocketConnectPort=xxxxx
SenderCompID=CAPSTP
# log configuration
FileIncludeMilliseconds=Y
FileIncludeTimeStampForMessages=Y
ScreenLogShowHeartBeats=Y
#Filter heartbeats from output (both incoming and outgoing)
PS - Application work without CA certificate validation. Error comes when enabling CA certificate validation.

Yes, If the application previously worked with ssl. You dont need to do any changes in the application side. Normally Quickfix/j is processing ssl validation just like java. That means openssl and the java keytool will do the trick for you. So steps are listed below.
Create pkcs12 keystore using trust certificate, private key and ca
certificate.
$ openssl pkcs12 -export -chain -in certificate.pem -inkey encodedKey.pem -out keystore.p12 -name importkey -CAfile CAcertificate.pem
Enter Export Password: importkey
Verifying - Enter Export Password: importkey
Using keytool, import the PKCS12 keystore into the resulting keystore using by the quickfix/j called /root/.keystore. Again, you may select different passwords.
keytool -importkeystore -destkeystore /root/.keystore -srckeystore keystore.p12 -alias importkey
Enter destination keystore password: importkey
Re-enter new password: importkey
Enter source keystore password: importkey
Change the configuration file and copy the keystore to the class path.
SocketKeyStore=keystore.ImportKey
cp /root/.keystore keystore.ImportKey /your/classpath
Thats it.
Please note, Adding ssl key and certificates to the java keystore is not working for quickfix/j due to quickfix/j is maintaining its own keystore. So make sure you add the keystore to the class path after the key adding process.
Reference - https://blogs.oracle.com/jtc/entry/installing_trusted_certificates_into_a

javax.mail.MessagingException: Can't send command to SMTP host;

I have imported the certificate to cacerts (to where the JAVA_HOME is pointing) but still getting this error. Not able to figure out the issue. There is no firewall issue from client's mail server which is a Microsoft ESMTP server. I am able to telnet this from my server. Tried SSLpoke but it's getting timed out. Tried tcpdump of port 25, can see the communication back and forth. Basically trying to a trigger an outbound email from the mail server.
The detailed error log is:
Caused by: javax.mail.MessagingException: Can't send command to SMTP
host; nested exception is:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1420)
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1408)
at com.sun.mail.smtp.SMTPTransport.ehlo(SMTPTransport.java:847)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:384)
at javax.mail.Service.connect(Service.java:297)
at javax.mail.Service.connect(Service.java:156)
at javax.mail.Service.connect(Service.java:105)
at javax.mail.Transport.send0(Transport.java:168)
at javax.mail.Transport.send(Transport.java:98)
at com.issuetracker.esb.mail.GmailImpl.transportMessage(GmailImpl.java:94)
at com.issuetracker.esb.mail.Mail.sendSRMail(Mail.java:188)

Did you use the -trustcacerts parameter when importing the cert with keytool?
Edit: My conversation on this topic has covered specific reasons for the error to occur but did not have the appearance of an 'answer', so here's a rewrite.
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
This error indicates that a valid certificate chain for the purposes of trusting an incoming certificate could not be obtained from the resident keystore file being used by the running JRE (by default, in the JRE's jre/lib/security/cacerts file).
Typical causes of this include:
Neglecting to include the parameter -trustcacerts when importing the certificate with the keytool command.
When the JRE is looking for certificates it knows about to match the incoming one, it will only consider the certificates that have been marked as trusted in this way.
The certificate has been signed by a root CA for whom the JRE does not already have the root certificate installed for.
Typically this is caused by having the certificate signed by an unknown root certificate authority (CA), such as a company's own internal CA that the JRE knows nothing about (yet), or even by some third party root CAs that aren't as popular as some other big-name vendors, and so whilst a browser or OS may have a root certificate already, Java may not have shipped with it.
To rectify this, you will also need to obtain and install the root CA certificate and mark it trusted too.
There are also companies that provide certificate signing that are acting as intermediaries, meaning that they don't have their own root CA themselves, but have been given a certificate by a trusted root CA to allow them to further sign certificate signing requests (CSRs).
In these cases, whilst you may have your own certificate and the underlying root CA already installed and trusted, unless you also obtain and install the intermediate certificate, then the 'certificate chain' is broken and a valid certificate path cannot be made.
So possible solutions in summary include:
Perform all certificate installations for other sites with the -trustcacerts parameter.
Check that the root CA certificate exists in the keystore file also, if not, obtain and install it using keytool -importcert -trustcacerts as well.
Check if there is also an intermediate certificate to complete the full chain, and if so, obtain and install that using keytool -importcert -trustcacerts into the keystore file also.
Note: Examining the .crt file in Windows by double-clicking the file can give you an opportunity to examine the certificate path and see if and which root and intermediary CAs were involved to help show what you will need.
Once a complete and valid certificate chain has been installed and trusted into the keystore file, the error should pass.

Installation of WildCard SSL certificate (By Comodo) on Tomcat Apache Web Server

I am installing a wild Card SSL certificate to my keystore which will be used for Apache Tomcat web server.
Description :
My Tomcat Server is installed on windows 2012 server.
And I have certificates provided from COMODO.
The wildcard cert I'm using has already been used previously on a few servers. so I am directly installing same on my apache tomcat server .
so what I've generated a public keystore using keytool providing the same information used while purchasing the certificate using following tool command.
keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tomcat.keystore
Then I have attached my certificates to the generated keystore using following commond
For "Comodo" certificates
i.keytool -import -trustcacerts -alias root -file AddTrustExternalCARoot.crt -keystoreselfservice.keystore
And I have used correct chain of installation of certificate like root , all intermediate, primary from above command.
And while installing each certificate i received the following message
"Certificate added to keystore"
Though I have not got any error .
And when i have opened my keystore there were no certificate chain , means there is individual entry of each certificate . but there is no chain hierarchy of certificates like Root then intermediate then primary.
And in my final PI or certifcate, i am getting provider as local first name instead of Comodo .
EXAMPLE :
CN=nims.ABC.com,OU=abcCommunications,O=abc Group LLC, L=Roseville,ST=Minnesota,C=US
Provider must be
CN=COMODO RSA Organization Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
So I would like to know which steps I have missed or used any extra steps .
Please provide a solution to install a wild card certificate .
Thanks in advance

You did everything correctly. The trust chain is important for another aspect. If you trust one 'certificate' of the chain, you trust the following 'certificates' of the chain too. So to trust all certs of a CA you just have to trust the root CA's cert.
What you realy need to make the wild card certificate work on you server is to import the private key part of it.

I assume you mean Tomcat using Java SSL (JSSE) not APR/Native (OpenSSL). If you want Tomcat-APR, change your question.
If the cert you want to use is already in use on other servers, and you "generated a public keystore using" the keytool command you showed on the NEW server, you generated a NEW KEY which is different from the key the other servers used and different from the key included in the certificate, thus the certificate DOES NOT MATCH that new key and cannot be used with that new key. You also implicitly generated (and have not replaced) a self-signed cert, with both subject and issuer (what you call provider) identifying you rather than a CA like Comodo. This certificate is not good for general use but can be useful for some testing, which is why keytool does it implicitly.
You need to get the certificate, the ALREADY EXISTING private key that MATCHES the certficate, and the needed chain cert(s) into your JKS as a privateKey entry. If an existing SSL server is Java (using JSSE), just copy its JKS. If you want or need to change the password(s) on the copy for your new server, see keytool -storepassword and keytool -keypasswd.
If an existing server is OpenSSL (including Apache httpd and nginx), convert the OpenSSL PEM format to PKCS#12 (preferably on the old server); depending on that server's file layout this is something like
openssl pkcs12 -export -in certfile -inkey keyfile -certfile chaincert -out xxx
and then use keytool to convert PKCS#12 to JKS (preferably on the new server)
keytool -importkeystore -srckeystore xxx -srcstoretype pkcs12 -destkeystore yyy
Note you must use a password on the PKCS#12. This does not need to be the same as the old server keyfile (if any) or the new server JKS, but it's usually more convenient if it is.
If an existing server is IIS, you should be able to export the cert WITH private key AS PFX/PKCS#12 from the Certificate snapin of mmc, and then convert the PKCS12 to JKS as just above.
If an existing server is something else, add it to the question.

The Webserver I talk to updated its SSL cert and now my app can't talk to it

The webserver updated its SSL cert to a new verisign signed cert and my java app can no longer connect.
I am using java 5 with a date on the cert file Nov 2006 in /usr/java/jre/lib/security
I get
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1518)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:848)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
How do I install a new key supplied by the server?
From a different java instance I get
Certificate chain received from eservices3.bus.att.com - 135.38.253.93 was not trusted causing SSL handshake failure.
I assume that it is from the same root problem.
Update Before the remote server was updated this worked with our standard java install. I didn't have to install any certs to get this to work last time around.

Java tries to validate the certificate by following the chain of certificates presented by the server, until it finds one it trusts (i.e. one that's present in your cacerts file).
We can verify the chain manually using the OpenSSL command line tools:
simon#lucifer:~$ openssl s_client -connect eservices3.bus.att.com:443
<snipped>
---
Certificate chain
0 s:/C=US/ST=Georgia/L=Alpharetta/O=ATT Services, Inc./OU=ATTIT/CN=eservices3.bus.att.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
Now, here's the problem: the issuer (line beginning i:) "VeriSign Class 3 Secure Server CA - G3" is an intermediate certificate, not a root. The AT&T server is misconfigured, and should be sending both its own certificate ("eservices3.bus.att.com") and the intermediate, so that Java can verify the chain all the way to the root.
To illustrate another way, the chain should look like this:
1) VeriSign Class 3 Public Primary Certification Authority - G5 (root)
^
| signed by
|
2) VeriSign Class 3 Secure Server CA - G3 (intermediate)
^
| signed by
|
3) eservices3.bus.att.com (server)
the root (1) is in cacerts - ok
the server certificate (3) is presented during the SSL handshake - ok
but: Java has no knowledge of the intermediate (2) - so can't verify the chain end-to-end
To fix this, you can either:
ask AT&T to fix the server so it sends both the server and intermediate cert during the handshake, or
import the intermediate cert into Java's keystore
The first solution is preferable, since it helps everyone (not just you) and is slightly less risky (you might not notice if the intermediate cert became compromised).
If you want to import the cert as a temporary measure, grab it from VeriSign's support pages (it's "Secondary SSL Intermediate CA Certificate"), then:
simon#lucifer:~$ keytool -importcert -alias some_alias_of_your_choosing \
-file intermediate_cert_path.crt \
-keystore your_cacerts_path
Enter keystore password: *****
Certificate was added to keystore
To remove the cert (once AT&T get their act together):
simon#lucifer:~$ keytool -delete -alias same_alias_as_before \
-keystore your_cacerts_path

It sounds as though your server (or application, but more likely the server) doesn't trust the root certificate that verisign has issued this new certificate from. Once you trust that cert, you'll trust all the certs chained to it.
The verisign root CAs can be found at the below link:
http://www.verisign.com/support/roots.html