I am using my SAP Business Connector 4.6 server as a client to HTTP post data to another partner’s BC system. They have their port set up as “request certificate”. I have logged on to their site using IE and downloaded their certificate, and installed it on our system. I then attempted to post (using pub.client:http), and got “Server Certificate rejected by chain verifier”. So then I extracted the CA certificate (Verisign one) out of their certificate and installed that one as well. Next when I attempt the post, I then got “Peer sent alert: bad certificate”. So then I sent the partner an updated copy of our certificate and they installed it on their BC system. This didn’t seem to have any effect, as I still get the error “Peer Sent alert: bad certificate”.
From this error, I assume that the handshaking is started, and our partner cannot verify my cert? My cert is certified by verisign, and doesn;t expire till next year. What could the problem be? Maybe our partner has not installed my certificate correctly? Or is the problem at my end? Please help!
I did actually read this thread, and applied the watt.security.ssl.client.ignoreEmptyAuthoritiesList=true parameter to my BC, but this didn’t help.
I know my certificate is valid because I can log onto my own BC system through IE and the certificate is fine. If I am posting to another BC server, do they need both my certificate and my certifying authority certificate?
You need their complete certificate chain in your system, the link should not be broken or expired. The error you are getting is basically same, you will get certificate rejected for the first time and then onwards you may get peer sent alert bad certificate, or that is the way I had noted it. If you restart the servers now you could notice this, but I could be wrong here.
Also make sure that you are making the chain in the proper order.
Thanks for the note. What do you mean by “making the chain in the proper order”? I went to their website and downloaded their certificate, which I then installed and then I opened the certificate file and extracted the CA certificate, and installed this as well.
I also got them to do the same on their end. Note that I am the one posting to them (they are the server). They are using a reverse invoke environment, but I am using just a single server. Does the word “peer” in the error message refer to one of their BC servers (their external BC system)? could it be that they installed my certificate on the wrong BC system in their reverse invoke environment? Which server should they install them on?
My message seemed to change from “Server certificate reject by chain verifier” to “Peer Sent Alert: bad certificate” when I decided to install the certificate of their CA as well as their own certificate. I thought was a step forward, but maybe not?
Sorry I need to correct few of my points here. (Am I slow since I am fasting, or lazy…?)
When I said “You need their complete certificate chain in your system” I meant they need your complete chain on their system. The chain should include your cert, intermediate ca, and ca.
and when you connect to them, the server would request for the complete chain, so you should be providing the chain with your cert, inter ca, ca and all in the same order. You need to create the chain in the order using developer before you make the call. Supplying just your cert and ca might not be enough sometime. Sometimes a ca like verisign might have their inter ca embedded inside. look at the certificate for more details.
Its kind of difficult to explain but not hard for a hands on thing and you will find it fairly straight forward when u r in the right track.
Good advice Thahir. I think too that Matthew’s problem will be solved if his partner installs Matthew’s CA certificates in their BC trusted CA directory (remind them to restart to pick up the change).
Once you have a lot of partners using X.509 authentication, it can get troublesome to check if a CA is trusted by IS or not. So I wrote a little procedure to check if a CA cert is currently trusted by an IS server. It requires Unix and openssl installed but Cygwin on Windows ([url=“http://cygwin.com/”]http://cygwin.com/[/url]) should work too:
Note the serial numbers of the root and intermediate CA certificates of the new client certificate. This can be done in Windows by double-clicking the client certificate; then inspecting the CA certs in the certification chain.
Go to the directory where the trusted IS root CAs are stored:
eg: <b2bserver>/config/certs/CA
Use this shell command to generate serial numbers of these CA certs:
find | xargs -n1 openssl x509 -text -inform DER -in | grep Serial -A1
Check if the serial numbers noted in step #1 occur in the output. Note that openssl reports some CA certificate serial numbers with a colon ( between the hexadecimal digits (eg: “70:ba:e4:…”) but reports others with no colon in between digits (eg: “0x300000…”). You will need to grep/visually inspect for both cases.
If a serial number of a CA Cert from the chain is not found, install that CA cert.
This procedure can be useful when installing a renewed certificate. This is because a renewed client certificate may have a different certification chain than the expiring client cert it replaces. I recently saw this happen with a Thawte cert – the renewed cert got a different Verisign root CA.
As mentioned by Thahir the problem is with configuration of certificates at client side, most likely.
In webMethods, the certificate chain have to be complete and valid, else it will fail. We had similar problem, but in our case both client and server are webMethods.
In your case, you get the “Peer sent alert: bad certificate” and this could be due to the following.
Client is presenting wrong or incomplete certificate set.
Server do not have client’s CA certificates properly configured.
Case-1 can be cleared by checking your BC config.
Case-2 can be cleared by checking the logs of server.
I am trying to do a PUT/GET over SSL using java API. During handshake process the application verifies the client side HTTP server for certificate and can only go through the handshake process only if the certificate has the URL that is on the cert and the CA is trusted. The application tries thsi connectivity through proxy. So, during handshake process when the application expects the cert having CN = clientURL the reponse is CN=proxyURL. This mismatch fails the connection.
We are getting the same bad certificate error in one of our TN partner via PrimaryHttps handshake.
com.wm.app.b2b.server.ServiceException: java.io.IOException: iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: bad certificate
But if we use the trail certs it was success…
Using our original certs we followed the same procedure as we did for trial certs…All the certificates Server,Intermediatery CA,public cert,Private are in place aswell on our partner side…
Increased the logging=10 and checked the logs,but no use…
I received this error come up in my webMethods on Windows 2003 SP2 operating system. It turned out that there is a limitation on the number of trusted certificates that can be presented in Windows environment in a trusted store. The vendor removed one of his QA certs and the resend of data worked. Is this a known problem with windows? Has anyone ever heard of this before?
I think there is a problem in webMethods not in windows. webMethods is having limitation for keeping number of trusted certificate. I’ve faced this issue in wM6.5 and for that webMethods has given the fix as well. Please check with SAG support.
