I have searched in vain for a straightforward example of calling a web service requiring SSL authentication and that has a self-signed certificate. I already have the code to be able to trust all certs, so you don't need to provide that. Just a simple example of being able to provide to the service the authentication parameters - username, password, and any other authentication-related parameters, transports, and headers necessary to authenticate successfully and make use of the service. Right now I am using Axis 1.4. Your responses will be greatly appreciated. Thanks.
Have you tried this?
https://stackoverflow.com/a/3256676/372643
You'll need to initialise your socket factory from an SSLContext that trusts this particular self-signed certificate.
Alternatively, you could import this specific certificate in your trust store (cacerts in your JRE directory), or import it into a copy of this file and use it as a global trust store by pointing the javax.net.ssl.trustStore system property to it (the default password is changeit).
Related
I'm looking at hardening LDAP on my domain controller (DC). To do this I need to import a security certificate to the DC.
I don't want to self sign as I've been told it is not best practice and the service I wish to integrate with LDAPS (Mimecast) does not recommend self signing.
I've created my certificate request, based upon the domain's fqdn. e.g. mydomain.local
What I'm not sure about now is where I can get a certificate based on that request.
I'm familiar with SSL for HTTPS. That process makes sense to me, the certification authority checks that I own the domain and provides a certificate that I can then install on my web server.
Will 3rd party SSL providers let me configure a certificate with the common name "mydomain.local"?
Or am I looking in completely the wrong area?
Many thanks in advance for any help that provided.
The type of certificate is exactly the same type of certificate as you would get for securing a website, yes. However, the domain name must be a valid internet domain (not .local)
There is a good walk-through here for Using Let's Encrtypt for Active Directory Domain Controller Certificates, including all the caveats you need to be aware of.
We have a web server running on linux machine where we configured 'SSLVerifyClient' as 'require' in ssl.conf file.
Does this needs client who is utilizing the service from web browser(like firefox or chrome) needs a certificate.
If yes, then it is not possible to distribute client certificate to every user as there can be some thousands of users, how to overcome this problem.
If no, then how the data passed over network is secure? I know that certificate helps in encrypting data so that no one who don't have certificate can read data.
Please help me in clarifying my doubts
If you don't use client certificate, the https connection is still safe:
Only the client and the server can read/write the content
The identity of the server is assured by a certificate authority
Client certificate only give you client authentication in the beginning of the connection. To encrypt the data, the public key of the server is used in the beginning (See public key encryption).
If you identify the client with cookies set after login/password submit, it is still safe: you have identify the client.
When SSLVerifyClient is set to require, the client MUST pass a client certificate. You would generate these via OpenSSL, and sign them with a certificate authority that you install via SSLCACertificateFile.
How you distribute those certificates is an issue you'll have to solve yourself.
I have a tomcat application that invokes an IIS hosted ssl enabled, client auth enabled Webservice
This Tomcat application talks to multiple wenservices and probably each of them require client auth along with PKI authentication.
For the IIS Webservice the wsdl url can change hence I use
javax.xml.ws.Service(url,qname) constructor by passing the url for the wsdl ...
The thing is I need to call the above with SSL with custom client key. How to I tell the above constructor to use a sslsocket that I create with my custom KeyManager ? I do not want to use
HttpsURLConnection.setDefaultSSLSocketFactory as that will enforce other outgoing ssl connection to follow to my keymanager which is exclusive to the IIS webservice.
Thanks for your reply.
If you follow the answer to your similar question on ServerFault and make sure that Tomcat's <Connectors /> don't use the javax.net.ssl properties, setting your keystore for the default key manager might not be the end of the world. HttpsURLConnections will only authenticate with it to server that ask for it (client-certificate authentication is always requested by the server) and that ask for a client-cert from a CA list that would match your certificate's issuer. This might not be such a big problem in practice.
If you think it's too big a problem, there seems to be an undocumented property called com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory. Its documentation is as follows:
Set this property on the BindingProvider.getRequestContext() to enable
HttpsURLConnection.setSSLSocketFactory(SSLSocketFactory). The property
is set as follows:
SSLSocketFactory sslFactory = ...; Map ctxt =
((BindingProvider)proxy).getRequestContext();
ctxt.put(SSL_SOCKET_FACTORY, sslFactory);
THIS PROPERTY IS EXPERIMENTAL AND IS SUBJECT TO CHANGE WITHOUT NOTICE
IN FUTURE.
I have a SQL Database which is storing my client side certificate for WCF service and other services. (X509 etc). I would like to use this Store (instead of 'My') to retrive this certificate (instead of declaring it in web.config) and then use it for WCF.
I have tried to search on this site and google but does not seems to be much of a help.
Currently I am doing
var targetEndpoint = new EndpointAddress(targetLogicalAddress, targetIdentity);
MyTransportPortTypesClient proxy = new MyTransportPortTypesClient("WebConfigSection", targetEndpoint);
So ideally I would like to get rid of the "WebConfigSection" and instead pass some sort of WCF object which has certifictate signed.
Does anyone know how to achive this?
I have finally solved this and Here's how I did it. (I'll share my experiece so everyone can use it) This is without using any machine CertificateStore. Its purely from Database to the client Proxy.
I have created X509Certificate2 Object and assign physical file (in byte[]). You can also put password if its password protected.
Then I have assigned the certificate to my proxy client.
Something like :
proxy.ClientCredentials.ClientCertificate = __MyCertificate
Now I have manupulated my clientproxy as I was inteneted to in my app.config. and that's it. All these properties will be in your proxy object.
Hope this helps.
AFAIK it is at least very difficult, if not down right impossible. WCF uses SChannel SSPI provider for the authentication and this SSPI provider will load certificates only from the SChannel CSP provider. In order to use a certificate from the database the certificate would have to be loaded first into a PROV_RSA_SCHANNEL CSP keystore and then the certificate context of this keystore would be passed to AcquireCredentialsHandle. For instance, this is how database mirroring is able to authenticate using a certificate stored in the database. While it is possible to do all these steps in managed code too, I'm not sure if is possible to plug them into WCF: I expect it is, but probably not for the faint of heart.
I have a WCF Server Deployed through IIS. I want to Create a Certificate for it. I could do this by making the server a certificate server.
But then when the client connects to that server I want the client to automatically trust the certificate without having to register that the server as a "trusted authority".
Is this possible?
All this seems a lot of work to put username password protection on a WCF Service!
The short answer is no the client will need to add the server cert root as a trusted authority.
The slightly longer answer is that there is a workaround for needing to implement transport security in WCF when using message based authentication - this workaround is usually used when you want to rely upon another security mechanism that the WCF server is not aware of, like an ISA server providing SSL.
Have a look at Yaron Naveh's post. The essential idea is that you create a transport binding that pretends that it is secure.
With all that, you still need security (you don't want to send your creds in the clear) and so will still need a trust chain for your cert. So, it may not actually help you, but hopefully it gives you some options to consider.
Edit
Sorry if my answer was misleading. The server certificate root cert must by in the client trusted store. My additional detail was giving another option for providing the security (you can use an ISA server with a trusted cert to give your SSL connection)
In a similar situation to yours (needing secure communication when pushing client applicaitons to non technical customers) I have programatically installed the needed root certs.
Here is an SO post that details how to do that: How can I install a certificate into the local machine store programmatically using c#?
You can if you add this to your code but be aware of what you are doing!
System.Net.ServicePointManager.ServerCertificateValidationCallback += ( se, cert, chain, sslerror ) => { return true; };
Well if there would be such a way, it would be a security hole.
If a certificate is not linked to a trusted authority it is easily forged. So your choice is either to link it one way or another (directly or through a parent certificate you control), or configure your client so that it does not require the certificate i.e. using http rather than https.
Just keep in mind that it leaves your clients open to a variety of attacks
Edit
One of the possible attack scenarios is a man in the middle attack - a program inserts itself between your service and the client and channels the information though itself. This way the intruder has complete control over the information flow.
It can make copies of passwords or it can "adjust" the results in both directions any way it wants. The only thing which prevents this from happening is the certificates. But if they are not rooted, they can be forged.