aspose file tools*
The moose likes Security and the fly likes Getting this error: SSL3_GET_SERVER_CERTIFICATE certificate verify failed Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Getting this error: SSL3_GET_SERVER_CERTIFICATE certificate verify failed" Watch "Getting this error: SSL3_GET_SERVER_CERTIFICATE certificate verify failed" New topic
Author

Getting this error: SSL3_GET_SERVER_CERTIFICATE certificate verify failed

Josue Nelson
Greenhorn

Joined: Nov 02, 2012
Posts: 11

We have IBM Sterling Connect Direct 4.2 on Windows 2003 Server, everything is working fine, even the SSL Configuration, we exchange files properly. Now, I have migrated all the configuration to a Windows Server 2008 cluster environment. Everything it's ok... I have configured the IBM Sterling Connect Direct 4.6.0.1 -even the SSL Configuration, we just have made a copy/paste of the certificates, keycerts and trusted files-. Everything it's ok and we are able to receive files under a SSL session. But... there is an exception.. The problem we are facing is when we try to send files to our partners we get this error:

Message ID: CSPA311E
SSL Certificate verification failed, reason= self certificate in certificate chain:
Followed by this error:

Message ID: CSPA309E
SSL3_GET_SERVER_CERTIFICATE certificate verify failed:
We are using exactly the same configuration, except by the IP and server name, that have changed. The certificates in any way are linked to the server name or the IP?

Any hint on this issue is very appreciated.


JN - SW Specialist
Maxim Karvonen
Ranch Hand

Joined: Jun 14, 2013
Posts: 103
    
  11
We are using exactly the same configuration, except by the IP and server name, that have changed. The certificates in any way are linked to the server name or the IP?


Yes, of course. The most common way in certificate validation is validation using certificate chain. In short, checks are performed in following order:
1. If a certificate is "root" certificate (no parent certificate authority) then it is checked against some list of preconfigured certificates (root certificates). These certificates are self-signed (exactly as your).
2. All intermediate certificate authorities' signatures and expire dates are checked.
3. "Target name" of the certificate is checked. Usually it is a domain name/server ip and it should be the a name used during connection. If your connect using IP then certificate should contain IP. If you connect using name then certificate should be issued exactly for that name.
4. Certificate expire date is checked.
5. Certificate validity is checked online or certificate is checked against list of revoked certs (if configured and available).

Skipping step 3 (name check) makes SSL useless. Attacker can create his own host and get a certificate for it from a trusted authority. Then he performs a low-level network attack (routing/dns attack) and redirects all packets to his server. According to all other checks his cert is valid. But data is not protected in any way. So, checking certificate name is crucial.

But you also have another problem. You cert is self-signed. Look at the verification order again. Do you see the only point where a self-signed certificate is mentionied? It is a list of predefined (pre-trusted!) certificates only. And this is also have it's reason. As you may know, issuing self-signed certificates are very simple (you already have one!). So, an attacker can create a self-signed certificate herself. If client trusts all self-signed sertificates, then she can redirect all traffic to her server and we got a successfull attack. You still may use self-signed certificates but they should be added to a trusted store on each client.

So, you have three possible solutions.
1. You may require each client to add your self-signed certificate to trust store or any other way accept the only certificate as valid. Changing certificate will require to reconfigure each client.
2. Issue a certificate with a correct name from some existing certificate authority (such as verisign, but there are many others).
3. Create your own certificate authority (self-signed cert). Require a client to install your root certificate into a trusted store. Then issue a certificate for your server (with correct name, of course) and sign it by your CA cert. In this case you may reissue cert for the server and this will not require a client to change configuration.

Josue Nelson
Greenhorn

Joined: Nov 02, 2012
Posts: 11

Maxim Karvonen wrote:
We are using exactly the same configuration, except by the IP and server name, that have changed. The certificates in any way are linked to the server name or the IP?


Yes, of course. The most common way in certificate validation is validation using certificate chain.


Maxim. Thanks a lot for your response, your recommendations are very appreciated. I checked the CN value and it is CN=My Company (with blanks). Is this field relevant? Through a keytool.exe I checked the certificate and don't see any information that sounds like server specific information.

To create a new certificate I must use the same values shown in the old certificate? or it may be a brand new self signed certificate?

Thanks again!
Maxim Karvonen
Ranch Hand

Joined: Jun 14, 2013
Posts: 103
    
  11
Is this field relevant?

Yes, CN is relevant. For a server certificate it should contain domain name (www.mydomain.com), domain-name mask (*.mydomain.com, google use such kind of certificates) or host IP (don't know if ip will work). Also some IPs/Names may be set in a "Certificate Subject Alt Name" extension if needed.

For issuing a server certificate you should use a server name as a CN. And i think it should not be a self-signed certificate. You may sign it by your existing certificate. It should change (first) error message because it complains about self-signed cert. And you should install your company's certificate (one which is self-signed and was used to sign host cert) in a trusted store on a client machines into a system-wide storage (you should ask Windows System Administrators of your system to do that) or into a Sterling Connect storage (if it is present, consult it's manual). Or maybe you just should install you self-signed certificate into a trusted storage and use it as a server cert, but this may not work.

As you see, both ways requires to install some certificates into a trusted storage. You wrote in the first message that you installed trusted files. So you should at least know where they are (and where to install new certificates). I am curious why system does not accept self-signed cert as trusted if it is present in it's security storage (maybe you missed some of the required settings somewhere or system security was tightened). So you first should try a non-self-signed certificate and see which error message you will get. And then you can try to resolve a problem with trust setup if it will remain.
Josue Nelson
Greenhorn

Joined: Nov 02, 2012
Posts: 11

Maxim,

The procedure we have followed in the past to generate self-signed certificates:

1. Through the Sterling Certificate Wizard (a software to create our own certificates or create the skeleton of a CA) we create a self-signed certificate. So at this point we generate two files: a private key file (privatekey.txt) and a certificate file (certificate.cert). (CN=MY COMPANY and a server certificate)
2. Providing the private key and the certificate we generate a key certificate (keycert.txt).
3. Finally we make a copy of certificate.cert and rename it as trusted.txt, within this trusted.txt file we attach the other parties trusted files.
4. Now, within Secure+ -the Sterling Connect Direct software to manage the secured sessions among the nodes- we use the trusted.txt file and the keycert.txt file to set up the configuration

That's the process and have worked for us in the past.

As you see, both ways requires to install some certificates into a trusted storage. You wrote in the first message that you installed trusted files.


I'm not very literate about SSL and.. well.. I'm working on that... but... when you refer to a trusted storage, in our case it refers to a .txt file? I don't think we install the trusted files... we just point to the files. When the other parties for example update their certificates they send us their certificate and we attach it at the end of the trusted.txt and it works! Do you think that re-generating this from scratch will work? I'm sorry about the misunderstandings .

Thanks again Maxim. Very instructive comments and very helpful.

Kind regards.
Maxim Karvonen
Ranch Hand

Joined: Jun 14, 2013
Posts: 103
    
  11
Hi, Josue.

I does not know what Sterling Connect Direct is. Probably your trusted.txt IS a trusted storage for that product but I can't be 100% sure. And probably your process is correct. But the error message says that there is no trust relation. I also think that "keycert.txt" is a certificate signed by your certificate.cert. In this case "certificate.cert" is a "Certificate Authority" and keycert.txt is certificate signed by that authority. So this general scheme is fine. But somewhere mapping between this "general" scheme and concrete implementation is broken.

One possible cause. Did you upgraged your Connect Direct from 4.2 to 4.6.0.1 version? Newer version may ignore some old configuration files. Not sure if it is your case. Or maybe some small but crucial checkbox was missed somewhere in configuration, etc...

Sorry, I cannot help you with your concrete product (except giving some general SSL-related info). But in general I would try following things to diagnose problem:
1. Use a fresh (non-trusted) self-signed cert on a server to see an error message.
2. Use a non-self-signed certificate for a server. Don't install a self-signed cert into any trusted storage yet. See an error message and check if it differs from a step 1. I think it is a keycert.txt (but it may be not what you need).
3. Install certificate from step 1 (that fresh non-trusted cert).
4. Try to get an error message that differs from that on steps 1-2. You may try both self-signed and non-self-signed certificates. Your goal is to get new error message at least with one of them.
5. Try to get a correct connection. Probably you will get it already on step 4.

This approach is quite general. Just get a new "fresh" setup, follow standard steps and try to get things work. If things does not work, refer to the product documentation (for the proper version, of course). And only after this simple setup works try to fix your production environment.
Patrick Do
Greenhorn

Joined: Feb 17, 2014
Posts: 1
Hey Joshua...I'm not sure if you have resolved your Self-Signed certificate issue. I had the same error as yours and here is what I did to resolved
1. Placed all of my partners trusted certs into my trusted cert and name it trusted.cert and this file into the "Trusted Root Certificate File" field.
2. Placed all of your partners trusted certs on your C server (Run MMC to add them) so they can be valid.
3. Place the KeyCertFile.keycert into the "Key Certificate File" field, this is the key certificate file at the bottom when I use the "Generate Key Certificate" tab. I give it an .keycert extension.
4. If you use the .Local node your authoritative source (master) then you need to set this node to use either enable tls or ssl and enable override.
5. The rest of the entries need to set to "Default to local node" so they can inherit the settings from the .Local node.

Good luck.

Patrick
Josue Nelson
Greenhorn

Joined: Nov 02, 2012
Posts: 11

Patrick Do wrote:
1. Placed all of my partners trusted certs into my trusted cert and name it trusted.cert and this file into the "Trusted Root Certificate File" field.
2. Placed all of your partners trusted certs on your C server (Run MMC to add them) so they can be valid.
3. Place the KeyCertFile.keycert into the "Key Certificate File" field, this is the key certificate file at the bottom when I use the "Generate Key Certificate" tab. I give it an .keycert extension.
4. If you use the .Local node your authoritative source (master) then you need to set this node to use either enable tls or ssl and enable override.
5. The rest of the entries need to set to "Default to local node" so they can inherit the settings from the .Local node.


Hey Patrick, your procedure is absolutely right.

Thanks for sharing.

JN.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Getting this error: SSL3_GET_SERVER_CERTIFICATE certificate verify failed