We have a Webservice Application running on Tomcat.
This is SSL secured. We need to share our public key to every client trying to access our web services. Is it possible to disable the trust certificate verification ?
By default, all TLS clients should verify the servers to which they are connecting. Any other default behavior would be dangerous.
The client is the party performing the verification in a one-way TLS handshake (that is, when there is no client-authentication being performed where the client also presents a certificate to the server).
There are only two ways to avoid distributing your server's certificate to all possible clients:
Get your server's certificate signed by a trusted Certificate Authority (CA)
Modify all possible clients to ignore any problems with your certificate (such as not trusting it)
These days, with free domain certificates available from e.g. Let's Encrypt, it's silly not to use a certificate signed by a legitimate CA.
Related
We are using WSO2 integrator 6.4. To be able to connect to 3rd party HTTPS servers, we need to add server's certificate to client-truststore.jks. A lot of servers now use certificates from https://letsencrypt.org with 3 months TTL.
That means we must renew certificates every three months for every 3rd part server in our enviroment otherwise we get "Error in Sender" error.
Is there a way to disable certificate checking in WSO2 EI at all?
Or maybe it is possible to make some automatic scenario to renew certificates in client-truststore.jks?
Or can we check certificates in client-truststore.jks inside wso2 ei itself and send warnings before expiration?
A little basic in TLS trust.
When do you have explicit trust, trusting individual certificates (often done for self-signed certificates). Indeed this approach creates significant management overhead, mainly when onboarding, offboarding new service hosts or with short-lived certificates.
For TLS (SSL) an implicit trust is used. Your application trusts a list of (long lasting) the issuers - Certificate authorities (CA). Event the list of the CA certificates change over time, so some manual management may be necessary anyway.
Is there a way to disable certificate checking in WSO2 EI at all?
Yes, there is (in axis2.xml), but that lowers the security and the traffic would be vulnerable to a man-in-the-middle attack.
We solved this issue by adding only root CA certificates of letsencrypt to client-truststore.jks.
Yes, this is the correct approach. If you have closed environment (not able to access internet), you may need to add all the certificate chain (root and iternmediate signing certificates)
We solved this issue by adding only root CA certificates of letsencrypt to client-truststore.jks. That was enough for wso2ei to trust all servers with certificates of Letsencrypt.
I am building a C++ application that needs secure connection to an SSL enabled server. I have read that for HTTPs to be fully secure, it requires the client to also use a valid certificate. But for my application, the certificate would be on disk so anyone installing the app would have access to the file. I came to the conclusion that the SSL certificate is not necessary for the application.
Am I right? Does an attacker could, somewhat, intrude into my SSL server?
Thanks a lot!
Secure HTTPs connection
When connecting to a TLS (nowadays)-enabled server, it's the server certificate that is mostly relevant (although some servers request a specific certificate from the client for authentication, but that's rare since a cert isn't as easily managed as a username+password).
That means that you don't need to have a trusted certificate, since one is generated (self signed) at runtime when neeeded as part of the TLS handshake.
The same happens in some TLS-enabled services outside WWW, for example, a SMTP TLS server's certificate is practically never checked against a trusted root.
Now If you are programming a WWW server application, yes you need a trusted cert. Check Let's Encrypt.
I am currently writing a desktop app which will need to communicate with PHP scripts on my remote server via https(with a self-signed certificate). The server-client communication code is still in the planning stages, however because I haven't yet figured out how to verify (on the client) that I am actually communicating with MY server. I'm presuming that there is some way to verify the servers identity using the certificate. I am intending to use WinHTTP for the https communication, providing it has all of the functionality that I need.
To greatly oversimplify things: clients verify the server's certificate by using a hardcoded list of trusted certificate authorities. The certificate authority list is an internal list of certificates that's baked into the client, and the client verifies that the certificate presented by the server is signed by one of the certificate authorities that the client trusts.
So, no matter what you end up doing, your client will have to keep some kind of a list of certificates that it trusts. This is a fundamental aspect of the TLS trust model. You could simply include your self-signed certificate with the client, and the client verifies that that your server presented the same certificate.
But the right answer is to run your own certificate authority. It involves some additional advance prepwork, but the end result will work much better. Instead of the several dozen, or so, standard certicicate authorities that are either included in your operating system, or your browser, your client will have exactly one trusted certificate authority in its trust list: your own certificate authority, and your client will verify that your server's certificate is signed by your certificate authority.
I have a web service that clients will have and I want the data that's sent to the server encrypted. To test this I used a self signed SSL certificate. I know that when you use a self signed cert and when you navigate to whatever address is using it that the web browser will warn you that it's unsafe etc.
I am wondering if I'm I going to run into any problems if I used this certificate instead of a verified one when the web service goes live?
Also I don't have a domain name for the server, so I am just going to use the IP address given by my ISP, is this ok to do so with the certificate, because everywhere I read about them people are talking about using them with domain names?
An SSL certificate is usually issued to a domain and is signed by an issuing authority. When a browser connects to a server the server presents its certificate to the client. The client then verifies the certificate by checking if the domain that it is accessing is the same one as mentioned in the certificate. Also, it verifies its trust chain. This means that the issuer's certificate should also be valid. If the issuer is not the root signing authority then the issuer's issuer's certificate is verified. And, ultimately the root signing authority should be trusted which means the root signing authority should be in your truststore. All major signing authorities like Verisign, Thawte etc are by default in the JDK trustore hence if you have a certificate signed by them then you do not have issues in the verification of your trust chain. If your certificate is signed by an authority that is not trusted then you need to import the issuer's certificate in your trust chain manually.
Now, when using a self signed certificate, the entity to whom the certificate is issued is itself is the root signing authority. And hence the certificate should be imported into your truststore manually. You need to do this to get your SSL handshake through. But this alone does not solve your problem. Since, you are not using any domain name, your IP is likely to be changed every time you restart your server if you are obtaining your server IP automatically through a DHCP server. If this is the case then even a trusted self signed certificate won't work once the IP changes. Because, the certificate is issued to an IP and once the IP changes the certificate would become invalid. To get around this you need to get a static IP address for your server from your network admin. Then generate a self signed certificate for your static IP. Then ask your clients to add your server certificate in their trust store.
This would be a bit tedious for your clients. But, if you have a fixed number of clients and the client machines are under your control then you could add the server certificate to the client trust store yourself. But, if your server is open to all or have a huge number of client then I would suggest to get a certificate signed by a well known and trusted certification authority. Again, you would still need to have a static IP irrespective of who signs your certificate unless your server gets a domain name.
The issue with self-signed certificates is the same in any scenario, browser or non-browser: it assures absolutely nothing by itself. The purpose of SSL is two-fold: encryption and authentication. Typically both aspects are being used/required by SSL clients for a connection to be really regarded as secure.
For authentication ("who am I talking to?"), certificates are used. To authenticate your peer with a certificate, you will either have to have a copy of that certificate to compare to, or you will need to have a copy of the certificate of a signer of that certificate to compare the signature to. If you have neither, the certificate doesn't assure anything.
Meaning: self-signed certificates are fine if the client has a copy of that certificate and can trust the source of where they got the certificate from. If you have a very narrow use case where every client that's going to connect to your web service will have had prior contact with you (e.g. via email) and you are able to give a copy of the certificate to them for them to install into their local trust store, then they are able to establish a secure and authenticated connection to you regardless.
This is not workable for a typical website with arbitrary, random visitors; that's what signed certificates are for, where an already trusted entity can vouch for a heretofore unknown 3rd entity. It may be workable in a vendor-customer scenario though.
Having said that, certificates are dirt-cheap to free nowadays and lend more credibility and professionalism to your service.
And yes, certificates can be issued for IP addresses.
I need to secure communication between my application and my Web Service.
I own both the application and the Web Service, and I was wondering if it is possible to use HTTPS to do so.
I don't need a certificate to prove to myself who I really am (!), so I don't want to buy an SSL certificate from a Certificate Authority. I just need to make sure no one can intercept the data I pass as WebMethod parameters; Can I create a free certificate and use that to secure communication?
One other thing: I don't want to be forced to get a dedicated, public IP address for my Web Service since it is hosted on a shared Web server.
Definitely it's doable, but hinges on a few conditions.
Create your own self signed certificate. The lack of a certificate authority won't matter in your case because your app is your own consumer.
The host must allow you to configure your IIS site with an SSL cert. Hopefully the tools they provide are good enough.
The shared IP that your web site has currently cannot have more than one certificate bound to it. You're now at the mercy of your host to not move your site to a different IP. It may or may not have an SSL cert on another site at that time. Basically - the first one wins. An IP cannot have more than one cert-secured website.
There are many articles out there showing how to create and install a self signed certificate in IIS. What you need to remember is that this certificate will not be valid as it is not delivered by a certificate authority. Once you set a certificate on the server side you need to indicate to the client to accept the invalid certificate by using the ServerCertificateValidationCallback property:
ServicePointManager.ServerCertificateValidationCallback =
(sender, certificate, chain, sslPolicyErrors) => true;
You can't use a SSL certificate (self signed or otherwise) without a dedicated IP address. Unless your shared hosting provider provides a shared SSL certificate on your IP, you will need to purchase a dedicated IP.
If you want to go through the trouble of doing it, you can use a self-signed certificate and have a tertiary server (or use the IIS server that is self-signing) to be your own certificate authority. This would allow you to generate your own certificate for free, then since you have control over the servers, you could just add your CA server as a trusted and intermediary root certificate authority.
Creating Certificate Authorities and self-signed SSL certificates