I'm trying to connect my iOS app to my java spring backend using ssl. As I am deploying my backend locally, I am trying to connect it using my own certificates for development.
For my spring backend, I have create my own CA, signed a certificate with it, and added them to a keystore.jks. I configured the app accordingly, and when I go to https://localhost:8082/blabla, AFTER trusting it, it works fine.
However, I have no way of trusting it on my iOS app, so it fails. I tried installing my Custom CA on my iphone, but still. The curious thing is on my iphone, on profiles, I can see my custom CA and it has the green tick and says verified. I thought this would have been enough to trust the other certificates
Any ideas on what I am missing/doing wrong?
Other info:
On my iOS app I am using Alamofire to make the requests.
Not a proper answer, but might be useful for someone:
I could not trust my own CA on an iphone, and could not connect unless putting the exception to ATS on info.plist.
However, Let's Encrypt now exists and it's on open beta! You can get a proper certificate there and forget about it (As #zaph suggested, you have to remember to renew it after 90 days, also you need to have a proper domain). This was a better option at least for me than creating my own certs.
Related
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'm writing a J2ME application that make HTTPS requests on a phone with outdated root SSL certificates
and I wanted to ask is there a way to include a root SSL certificate as a resource in the application and let The HttpsConnection API validate against this root certificate?
You can't supply certificates with your application for working with default API. But you can use libraries, which can replaces this API, for example: https://github.com/rotsenmarcello/mhc
If you want install root certificate, this question is very device-specific and have no single answer.
If we're talking about a specific SSL certificate you just need to install on the phone, to be used by the phone browser, I think there's a way do to it with JavaME:
Include the certificate inside the JAR.
Code a simple webserver that serves the cerfiticate file, and start it.
Call platformRequest("http://127.0.0.1");
This should theoretically open a new native browser and the user downloads and installs the certificate.
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.
i have developed an application in java (J2ME),
and i want trusted domain for that application using goDaddy's certificate.
can i obtain it ?
let me re describe the full scenario.
i have developed an application.in which i want FILE IO operations to be done without the permission of user (for every read write, it means user will be asked only once.)
so to obtain that i want trusted domain for my application.
for that i need to sign my application using code sign certificate.
now go Daddy's certificate is not listed under Nokia 3110Classic, so i have externally added it in CA list.
but still its showing app signing option disabled.
so my question is can i obtain trusted domain using the goDaddy's code sign certificate ?
For an explanation about the MIDP security model, see answers to StackOverflow questions Application Error Occurs in Nokia 6300 and Privileged operations in netbeans mobility.
If the certificate you used to sign your MIDlet wasn't on the phone, just adding it to the phone may not be enough.
You probably need to add the goDaddy certificate to the MIDP runtime "trusted third party" security domain. Somehow. I'm not convinced that's possible on a Nokia 3110 Classic.
Godaddy certificates usually depend on a Starfield certificate. Make sure that is in place too.
Also, the app-signing might be off because you've only installed the public key.
Edit: Actually, the private key is not necessary on the box (nor desireable). I wonder if the box is missing the Starfield certificate.
I created a JApplet using Netbeans 6.5.1 that accesses a database. When the program is run by itself, it runs perfectly. The issue is when you try to put it online using a web application in Netbeans, it will not access the database. I was told by somebody that the problem is that Java security will not allow you to do this. Is this correct? How do I fix this problem? Thanks.
As already mentioned, an unsigned applet can only make network connection to the host from which the applet originated. However, if the database is hosted on a different server than the originating applet then you will have to make the applet signed. If the application is not for production use, you can self sign the applet (not suitable in production use where the signing has to be done by a trusted Certificate Authority. Certificate authorities typically charge a fee for the service of validating their clients' credentials.) However, for testing and demo purposes, you can create a self-signed certificate. With self-signed certificates, the browser displays a warning to the user mentioning that the information given in a self-signed certificate has not been validated by a trusted third party (Certificate Authority).
For self signing the applet take a look at the following links:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html
http://www-personal.umich.edu/~lsiden/tutorials/signed-applet/signed-applet.html
The other things to keep in mind are the JDBC driver types to use. Type-1 and Type-2 drivers are not suitable to be used within applet due their dependence on native binary code. Type-3 and Type-4 are ones you should be using to connect to database from within an applet.
The best solution is to NOT make database connection from an applet (if possible) but instead use a server side application to connect to the database on behalf of the applet.
as Clint pointed out, an applet is only allowed to connect to it's origin server.
to work around this, you can sign your applet with a certificate from a root authority, but certificates cost 200-400$/year.