I am working on a WCF service that will be running on HTTPS over internet. I am planning to secure the WCF service using X.509 certificates on Service(Server Certificate) and Client side(Client Certificate). Following are my questions.
The client is going to be a Java application, will there be any compatibility issues ?
IS there any issue with WCF running in clientCredentialType="Certificate" mode over HTTPS ?
Before posting here I did a lot of research and went through good number of questions on this forum. But now I am at a point where I get more confused more and more.
Thanks in advance for all the help.
I assume you use only transport level security (ssl) and not message level security (ws-security). you should not have any special problems here. do note that most java clients use jks certificate format and on windows pfx is better.
Related
So i am developing an app which uses a rest connection to a database server. This server uses TLS encryption and has a SSL certificate. Im using OkHttp3.2 to manage my server connection. I can connect to the server without any problems and also encryption works fine.
My question is based on the certificate tester from java's SSL Engine. I can readout everything the Server send about the certificate (Serial, Signature...) but i cant see any information about validation or trust level like a certificate chain.
Does the SSL Engine tests the Certificate independently or do i have to do this manually?
And would OkHttp's certificate pinning do the Job?
And how would i readout the SHA checksum of the certificate like some ssl tester do? e.g. ssllabs.com
So Thanks to Pravin's comment i think i know everything i need.
If someone is intrested a little conclusion of the article:
Android's SSL Engine checkes validity of the Certificate at every Request. The Certificate is compared with trustet root certificates in local system storage (Settings -> Security -> Trusted credentials).
Certificate pinning would add a second security level, in fact it checkes if a certificate in the certificate-chain has a fringerprint which is equal to your setting. Usefull if you would only want to allow a certifiace of a specified provider to communicade with your app.
I'm working on creating a soap server using java for my company. We have a website that uses SSL set up already, and I'm interested in using SSL for the soap server from the start. I've searched for articles or information about how to implement this, but most of them that I found are things such as "you need a cert first" or are so old and missing parts that I cannot contact the creator.
How would I go about connecting the soap server using SSL? Is there anything special I need to do in the code to enable SSL? The cert is already applied and we have working HTTPS connections already running through our website.
Most (probably all) SOAP frameworks will support ssl. Here is a link with some example code for Axis2, Apache CXF and JAX-WS.
I'm beginner in SSL protocol. I want connect my application to a server. Server get to me itsCertificate File and wants my Certificate File. Certificate files are self-signed. My application developed by Java and server application developed by C. Server Certificate created by OpenSSL.
I have private/public that is my self and server certificate file now.
I don't know what do I? I trying some day but don't get any result.
(Sorry if I am using the wrong terminology or grammar, I am learning english language.)
Edited
I research in web and found I must research for two-way SSL authentication by java Anyone have more information?
You're going to have to use an OpenSSL implementation for both the client and the server.
The protocol is standard, so you can use any implementation on each side.
Have a look at the client example here (in java):
http://stilius.net/java/java_ssl.php
Standard java classes are used, so you can also use this as a starting point to know what javadocs to start reading! ;)
As for client side, you can use openssl (it's a lib too). I've never donde SSL on C, so I can't help you there.
Generally, you'll treat the sslsocket the same way you'd treat an ordinary tcp socket. :)
As a side note, you may be interseted on using HTTPS, instead of raw SSL, depending on your application (just saying; you might want to consider it).
Not sure if I understood you correctly; but seems that your client is not able to connect to your server. You need to import your server certificate in a client truststore. Since your client is a java application you need your truststore in the java compatible PKCS format. Get help on creating a trustore using java Keytool utility. Since your server side is C application you need to create a C compatible truststore for the server side. You can do it by simply copying the PEM representation of the certificate into a file (cat server.crt > truststore.pem) to be used as the truststore. Since your certificates are self signed, copying just the endorsing authority's certificate ( which in your case is the server certificate itself) is sufficient. Configure your client and server to use their respective truststore and it should work.
We have to create a web service client using Apache CXF in Java. The thing is I cannot seem to get the SSL session to properly engage. Either it fails altogether, the server fails to decipher what is sent to it once the application data is transmitted or I fail to read the responses from the server.
However when trying the same transaction using a simple soap test client built in .NET everything runs smoothly.
Server is using double authentication.
Everything is certificate based (x509) stored in the windows certificate store (windows-MY and windows-ROOT)
edit
yes, double authentication is indeed client AND server authentication.
Thus far using the bountyCastle provider instead of SunMSCAPI seems to get further but still cannot get the client authentication to work.
PLatform of client CXF 2.2.9, Sun JDK 1.6_21
server IIS 6 ASP.NET unfortunately is all I could gather, I have no control over the server and must use it as-is.
update
I am using a JKS keystore now but still am getting the problem. It seems the client is not sending his certificate to the server as part of the authentication process. As a result I get a 403.7 error from the server.
Funny thing is that I receive this error message as an HTML page that must first be decrypted before it is readable !
Presumably, by double authentication, you mean you're using client-certificate authentication in addition to server-certificate authentication (which is more common).
It would be useful to know which versions of the platforms are used on either side, and which patches have been applied.
It's possible that some of the problem come from the re-negotiation fix to CVE-2009-3555 (or lack of fix).
The problem is a flaw in the initial design of the re-negotiation in TLS, which is what was used to re-negotiate a client-certificate. There are two ways of getting a client-certificate: either the server asks for it during the initial TLS handshake, or it asks for it during a subsequent handshake (for example, once it has figured out what the request was aimed for and/or when trying to access a certain restricted area). The second method is the re-negotiation. Unfortunately, there was a security flaw in the design of the TLS protocol in that respect, which has since been fixed thanks to a TLS extension described in RFC 5746.
When the flaw was initially disclosed (around November 2009), some platforms and libraries such as Sun Java or OpenSSL rolled out a quick fix which simply disallowed any re-negotiation (so only initial negotiation of the client-certificate would work). Later on, once RFC 5746 was written, these libraries started to roll out implementations supporting this extension.
As far as I'm aware, Microsoft's default in IIS and its web framework was to use re-negotiation and not initial negotiation. In addition, it didn't roll out the initial fix to disable re-negotiation (effectively keeping the known vulnerability). It only rolled out a patch (still tolerant to old implementations by default) quite recently: Microsoft Security Bulletin MS10-049 - Critical.
There is also an explanation of the problem on this Microsoft security blog:
http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-an-inside-look-at-cve-2009-3555-the-tls-renegotiation-vulnerability.aspx
Essentially, if you're trying to talk to a server that only supports the old negotiation style from a stack that only has the new re-negotiation style or no renegotiation at all, it's not going to work.
If your server is running using IIS or similar environment, you might be able to turn on initial client-certificate negotiation using netsh and its clientcertnegotiation=enable option.
Java doesn't rely on the OS certificate store and needs to use its own.
This will import your self-signed certificates.
cd JAVA_HOME/jre/lib/security
keytool -import -file server_cert.cer -keystore cacerts
I post this as an answer though I realize now the question was not formulated properly as I got thrown in a loop because the .NET example I had was actually performing a hack to get around the problem.
The proper question should have been
How to get Java to perform Client side Authentication on a server that does not ask for Ask for certificates ?
the answer is actually under our very noses, however to get to the answer one needs the correct question !!
Great thanks to Bruno who provided some very helpful information.
the solution can pretty much be summed up in these two questions :
Java HTTPS client certificate authentication
Client SSL authentication causing 403.7 error from IIS
Although the client is "not supposed" to send a certificate if not asked I found that by tweaking the client certificate in the keystore to contain the following :
Client certificate with all extensions
Client Private key
A concatenation of the client's complete certification chain.
push all this in the same certificate store and use it as keystore. Then load again the certification chain as a trust store. From there it should just work. This being said there is still a possibility for failure. the safest way to solve this particular issue is to have the server actively ask for a authentication certificate from the client by providing a list of accepted CA.
Hope this helps anyone else that can be stuck in the same problem, sure tooke me for a spin for a while before I reach the root of evil.
I am connecting to a simple XML over HTTPS web service and getting a security exception. My question is whether you think the cause of this is the cert on the web server, so I should talk to the server admin or if my client code should be handling this. I would love to hear if anyone has encountered and solved this issue. Is the solution found on client side or server side? Below is the exception.
Caused by: sun.security.validator.ValidatorException: Violated path length constraints
at sun.security.validator.SimpleValidator.checkBasicConstraints(SimpleValidator.java:243)
at sun.security.validator.SimpleValidator.checkExtensions(SimpleValidator.java:158)
at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:143)
at sun.security.validator.Validator.validate(Validator.java:202)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(DashoA12275)
at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(DashoA12275)
Thanks for any advice.
It's probably worth testing the client side first with openssl
openssl s_client -connect yourserver.com:443
Check out the man page for further options.
What happens when you access it with a web browser? Firefox should provide you quite some information on the server cert.
While it does not seem like you after client cert authentication this examples does show you how to use a custom SSLSocketFactory. It can also be set statically - if you don't have access to the connection.
From the stack trace, I would guess that it's a problem with the server's certificate (the trace originates from "checkServerTrusted" calls). You might want to try connecting to the URL with a web browser such as Firefox to see if you get an SSL error with more details.