I have written web service and hosted project on server with SSL certificate.If I want to call HTTPS url, I need to import certificate in JVM manually or through program on client side.
I can't ask any client to do extra work on his side before calling my https url, I would loose my credibility.
If any one knows how to deal with this, please help me on this.
Ideally, you should pay for a real SSL certificate (trusted by one of the common root certificate authorities), rather than getting a self-signed one. Then there won't be any need to important any certificates.
The point about losing credibility with your client is an important one, because that's precisely why you need to buy an SSL certificate - it establishes that an element (however weak) of authenticity... you might still be serving up malware or whatever, but there's still a paper trail back from the site serving the content to whoever paid for the SSL certificate.
Related
This previous question dealt with the handling of self-signed certificates in Java:
Accept server's self-signed ssl certificate in Java client
The accepted answer offers 2 possible options: (1) manually load the relevant certificate into the local keystore (2) circumvent UrlConnection's security with a bespoke TrustManager
In the context of a web crawler whose function is solely to extract content from remote https secured sites, what specific risks arise from option 2.
And, assuming those risks are deemed unacceptable, what alternative exists since it is not viable to manually extract the certificates and load into the local keystore.
Not only from option 2 but also from 1, the only risk is that there is no guarantee that the server your webcrawler is crawling is effectively the one you think it is. There are other risks but are not associated with the tasks a web crawler does.
For your second question: You need to identify why it is unnaceptable, because it is very easy to code in java to just accept the self-signed certificate. What specifically blocks you to code to accept the certificate? You can use a proxy server to automatically accept all certificates but this is a separate topic and it would be better to create a new question for it.
I'm hosting a web game on github pages. It's a react app that connects to a websocket server (via wss) running off of a linux box in my living room. I've generated a self-signed certificate for the server, and github-pages already has a Let's Encrypt certificate by default. Presumably because the cert is self signed, the client refuses to connect to the "insecure" server and I am not prompted to install the certificate or anything, because the client does have it's own separate certificate. Would just buying a real certificate solve all my problems? Should I just host the website from the same server and figure out all the stuff associated with that (I realize this is probably the best answer)? What's the public opinion on having separate ssl certificates for client and server?
you can add your self signed certificate to your local truststore, but it's a little work and everyone connecting to your site would have to do it.
buying a certificate would solve this problem, because it is then signed by a trusted certificate authority which allows everyone to verify your servers identity.
on the other hand, if you move your ui to the self signed server too, the web browser will prompt (respectively warn) the user about the untrusted certificate and the user is about to say wether he wants to advance to the site or not. this would "solve" the problem too.
last, but not least. it's quite common to have ui and backend separated and therefore having separated certificates too, but not in such little applications. in a big environment definitely worth it, because it's a separation of concerns.
I have a unique problem here-
The server is under our control and has already been updated with a new server certificate that is about to expire soon.
But the nature of our clients is such that updating the SSL certificates would require manual intervention to setup certain aspects for them to be up and running after that. We do not have enough time to make change and get all clients running before the certificate expires.
We are using one-way SSL i.e. only the client is validating the server certificate (TCP communication).
So my question is- Is there any way to force the client to accept the certificate beyond the expiration date so we get more time to update them all? We can make any changes on the server in the meanwhile but cannot touch the clients.
I ran a wireshark trace today setting the system date to beyond the certificate expiry on both the client and server, its the client that is throwing certificate_expired I believe in this case since the server already has the new server side certificate installed.
The communication doesn't even get to SSL/TLS messages by the looks of it, i.e. it fails before that.
The client is written in C and uses OpenSSL for establishing SSL connections and the server is written in Java.
I have tried using all sort of TrustManagers to accept everything on the server-side but the problem is the client it seems. The information being transmitted is not sensitive and if there is any way to do so, we can disable all SSL functionality to make it work, but again whatever we can do has to be done without touching the client.
Let me know if further details are required to make the situation more clear. Any help would be appreciated.
You didn't say so, but it sounds like you are using "self-signed" certs and that you are concerned about the time to go around the network and add the server's cert to the cert store on each machine. Assuming that is the scenario -- you have a very simple solution...just switch to a commercial cert. Comodo runs deals all the time, and you can typically get a year for under $100. They even offer free 30-day trials. https://ssl.comodo.com/
I'm trying to improve some code that enables logging in to our application using digital certificates, probably certificates stored on PKCS11 tokens.
It's a Java client server application, with the server on JBoss [Wildfly], and a rich Java thick client. We also have a GWT/Javascript based web client, but this doesn't yet support certificate auth.
The current implementation uses 2-way SSL authentication if certificate authentication is configured, i.e. the server will require a client certificate when the connection is opened. This causes some problems, and in trying to find ways to address them I've been searching madly to see if there is a standard, 'Right Way To Do PKI Auth To A JBoss Application'.
However just about everything I have found on the subject seems also to revolve around using two-way SSL, which kind of implies that is the Right Way to Do It.
It seems undesirable to me, in that the network transport is quite a low-level concern, heavily separated from the application logic and stuff like authentication and user management.
In order to prove the client is a valid user of the system (as opposed to merely someone with credentials endorsed by a CA in the server trust store), the server application logic has to rummage around looking to find the certificate that was used on the incoming connection in order to scrape the Common Name off it. I've discovered that javax.servlet.request.X509Certificate is a standard-ish parameter one can query on the servlet, so it ought at least to be possible.
The other architectural problem this causes is that our app requires reauthentication for the lifetime of certain sensitive operations. If one is using the SSL connection to prove the user has the private key, then logically that would require opening a whole separate connection.
Logically, authenticating with a certificate would seem to require
The server generating a nonce
The client encrypting the nonce using the client's private key
The client sending that encrypted value to the server with the accompanying public certificate [or certificate chain].
Now, that is exactly what happens during an SSL handshake, but obviously a whole load of other baggage comes with it that is irrelevant to the application-level concern of authenticating the user.
I thought about implementing the steps directly myself, but this would seem to violate the first rule of crypto (Don't implement your own crypto).
If the server generates random nonces then that introduces a level of chattiness and statefulness to the process, which is doable but a pain when you are striving for a stateless and clusterable server.
Time-based One-Time Password implementations circumvent this, and seem to be a standardized mechanism for 2-factor authentication that is getting support from Google+ and the like.
However I can't find anything in the way of out-of-the-box libraries that will let me build an implementation using certificates directly from an imposed PKI.
I'm new to SSL connections so here goes my question.
I have a desktop Java program in a JAR file. This JAR sends sensitive information over the internet to a remote Tomcat server. Of course I need to encrypt the data.
If I purchase an SSL cerfiticate say from Verisign, will the data sent over SSL be automatically encrypted?
I mean in my JAR, will I still need to do extra work like use Java encryption extensions API to manually encrypt my data over the SSL connection?
Thank you.
I mean in my JAR, will I still need to do extra work like use Java encryption extensions API to manually encrypt my data over the SSL connection?
Encryption will be done for you (with the Java Secure Socket Extension). Just establish your connection using https://. Maybe have a look at HTTP Client for a higher level API.
By the way, the certificate goes on the server side (unless you want to do client-authentication too in which case, well, you'll need a client certificate too).
And yes, you could use a self-signed certificate but one of the benefits of using a certificate signed by a well known Certificate Authority (CA) like Verisign, Thawte, etc is that you won't have to add it to the trust store of the client VM (unless you disable the verification mechanism).
Follow the SSL Configuration HOW-TO on how to setup https.
If your goal is just to get the encryptian, you don't need to buy a certificate. You can make your own. Buying a certificate just creates the verification chain back to verisign (or whomever) to give users a warm fuzzy that you're really who you say you are.
SSLSocket should handle most of the work for you.
All data sent over SSL is by definition encrypted, you do not need to worry about encryption at all. Also, you do not need to by a certificate to achieve that: you can issue one on your own.
If you'll set up the SSL on Tomcat and send your data over HTTPS then the encryption will be done for you. But you don't actually need to purchase a certificate if you only need encryption for your data channel, you could generate a self-signed certificate. Have a look at this page http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html on how to configure SSL for Tomcat. But note that HTTPS can be configured not to use encryption at all (at least on Apache httpd).
To answer your question, SSL implementations automatically encrypt the data. You don't need to worry about using additional encryption routines.
It might be easiest to purchase an SSL certificate because SSL implementations provide easy certification authentication using common root certificates and provide a verification service. However, you could save some money by using a self-signed certificate.
Even with a self-signed certificate, it's important to validate the signature on the server certificate from the desktop application when you connect to the server. This will prevent man in the middle attacks.
You won't have to add your self signed certificate to the store because you should be able to disable the automatic verification mechanism and use your own.