I have been trying to get openSSL/JSSE from Cpp to Java working for weeks. If I can't find a solution I am just going to disregard the whole idea. No matter what I seem to do I keep getting a "sslv3 alert certificate unknown" error. I have a self signed key that works fine on the server en of things but I get the error when connecting to OpenSSL's s_server utility. I have been looking for a solution for weeks. Help would be appreciated! I have a self-signed crt file and a server.key file. I put the cert in the java keystore but I still get the error
Your self signed certificate is probably what is causing your problem.
This site has basic dirty instructions on creating a CA and this site has similar instructions but is a little more verbose.
Here's the way you need to have this play out:
Create your CA
Create your certificate for the server
Create two keystores,
Server keystore containing the server private key, server public certificate (signed by the CA), and the CA certificate.
Client keystore containing only the CA certificate.
This site gives you the system properties needed to configure the java engine to use the keystores as well key stores and trust stores. The trust store will be needed on both ends to allow correct verification of the certificates in question.
As far as the s_client utility, you will have to use the -CApath option to point to the directory containing the CA Certificates you trust or -CAfile to point to your self signed CA as trusted.
Just comment back if you need more help. This is frustrating but once you get the basics down you'll be a pro in no time.
Related
I'm trying to use a Web Service but I have many doubts about the certificates, I'm quite a novice in this topic, The team that developed the web services sent me a document where explains how to use it but to enable the connection, I need to USE a certificate (X.509), I generated p7b certificate from they website and I imported that certificate in my local environment, Using Keytool -import it generate a JKS file but they warn that I should install "Entrust" (Root and Intermediate) certificates that they provide me I used keytool -import with these .cer files and the command generated one .JKS for each file, I installed those cer too, my question is:
To use that web service Which certificate file I need to attach in my implementation logic in java, the jks or p7b ?
How I can use this certificate in all the Test environment? (I don't know if this certificate can be use only in the PC that generates the CSR).
I'm trying to simulate the call with the SOAPUI app i'm getting the authentication error so Probably something is worng with the certificate.
He implemented all using windows certificate store and .NET they can't give me support for keytool.
To do client authentication (also called mutual authentication) in SSL/TLS you (your program) needs not just a certificate but a certificate PLUS PRIVATE KEY and usually intermediate/chain certs. There are canonically 5 steps in the process:
On your computer generate a key PAIR which consists of a privatekey and a publickey, and a Certificate Signing Request (CSR) which contains the publickey. These steps may be done separately, or combined in a way that you don't notice there are both a CSR and a privatekey.
Submit the CSR to a Certificate Authority (CA) along with evidence of your identity and authorization as appropriate, and payment if the CA requres it.
The CA issues an 'end-entity' certificate (in this case a client cert) containing your publickey and identity(ies) plus some other information and gives you this certificate, usually along with an intermediate certificate or sometimes a few intermediate certs that form(s) a 'chain' from the entity cert to a trusted CA root or anchor cert. A 'p7b' file is one fairly common way, though not the only one, of transporting a group of related certs, such as your entity cert plus your chain cert(s).
You return the entity cert and the chain cert(s) to your computer and combine with your privatekey from step 1.
You use the combination of privatekey PLUS certificate chain with various program(s) such as a browser, a utility like curl, or a custom application.
Details of steps 1 and 4 (and 5) depend on the systems and software you use, which you don't specify in any recognizable way, although it sounds like you are ending up in the Windows certificate store. If that is the case, and it is specifically the Personal section of the current-user store (as opposed to a machine account like SYSTEM), then when you run MMC (aka Administrative Tools) and select the Cert Mgr addin, or directly run certmgr.msc, the icon for the cert should have a yellow key at the left:
Contrary to your Q, Java JCE (at least Oracle-was-Sun Java on Windows) can handle this; run keytool -list -storetype Windows-MY -keystore NONE and see for yourself.
However, some (probably many) Java programs cannot. For those, you need a keystore file containing the privatekey PLUS certificates; to create that run the Export wizard and select 'Yes, export private key', then format PKCS 12 (aka PFX) with 'include ... path'.
Recent updates of Java 8 by default can automatically handle a PKCS12 keystore (look for keystore.type.compat=true in JRE/lib/security/java.security) and older versions can do so if the program configures the store type (I don't know if SoapUI does that). For older versions that require JKS, after exporting to PKCS12 to let's say mykey.p12 convert with
keytool -importkeystore -srcstoretype pkcs12 -srckeystore mykey.p12 -destkeystore mykey.jks
What you try to archivee is something called a mutual-authentication. In order to understand the basics you need to understand that the humans have simply concepted a password to lock and unlock informations by the same (symetric) password. Everyone who knows the one password can
read the message
rewrite the message to send false informations
this is dangerous. So they have invented two different passwords, one for writing (private) and a compleatly different one for receive(public), we call them asymetric. The problem in asymetric encryption was, that you can choose free only one password, the opposite password is calculated and can not be choosen freely.
Finally they invented certificates to simplify the process. Certificates contains strong Passwords packed into files. Without looking into the certificates you dont know if the passwords are private or public, that means p7b(pkcsv7b) and jks can contain the absolute same informations. The difference is the format only, like the difference between .doc and .docx.
The second problem
In the big japaneese war's spionage was a big thing, the agents gathered informations about the opposite at the point of tactics and send theese informations to their real lords to find weaknesses in the tactics/strategys. Whenever a spoin has been uncovered he has been turned into a double-agent faking honeypots to let the warlord make wrong decisions and fall into traps.
So as an warlord you must trust your agent ... but, how to be sure? Well, you can ask the other agents about the agent you have the informations from to have the guarantee that the message can be trusted. So the first agent must ask other agents to sign the message too, this question between agents is the CSR! If the other agent(s) sign too, we have a "chain of trust". Ok we have four parties now, the agent, the signing-agent(s) the enemy(hacker) and you.
What must be placed where? Well, assuming you are a warlord (server),
you need the public passwords of all your clients(agents) in a truststore to send them messages(download),
you need to know your private password to encode messages(posts, requests, uploads) your agents sent.
Assuming you are a agent(client/browser) of a warlord inside the enemys lines (open field of world-wide-web), you must store:
your private key, to send messages and sign messages of other agents
the public key of the warlord to encode orders of your master.
You have learned now that a certificate can contain aswell private keys as public keys. How to technically use them?
You lucky, the keytools is open source, download the sources from grepcode (click here) and you will have your implementations by copy-and-paste.
Some hints for mutual-authentication:
The server should not offer its public certificate because all authenticated clients already have the public certificate(key) in their truststore.
The client's certificate should be sent in a non-electronic way (printed as rf-code or whatever).
The client should presented the server's public key and the clients private key in two seperate physical letters (you may noticed if you use the electronic-cash-card (ec-card) you had two letters, one for the PIN and one for the ec-card).
I have gotten 4 certs (1 root, 2 intermediate, and 1 domain to be deployed in that order) from my CA and I am curious about what the process is for getting the chain imported into a keystore correctly. I was able to get the domain cert installed and desktops/laptops can connect securely but not mobile (I get the red x and the crossed out https in mobile Chrome). Based on this post, it appears that my chain is somehow messed up. This is the first time I have done this, so I tried using the keytool tutorials that had me create a self signed cert and then add the CA certs to the keystore, but that didn't work so I resorted to using this article that uses openssl to import just the domain cert and then convert the p12 to a jks. This article is what got me to the point where I could connect from non-mobile devices securely. But I am still stuck in non-secured on mobile. My CA is Comodo and the link I am using is here. Thanks!
It looks like everything is working now. I used the accepted answer here. It's weird and kind of wonky to have to manually paste in cert info, but it worked! If anyone else has a better process I'd love to hear it though.
I have certificate from GlobalSign.com ( .pem file). This file consists of 2 certificates inside (I've examined it with Portecle). Using Portecle I created BKS keystore and tried to use it in the app. I have read many different tutorials with similar topic. I've tried:
Security with HTTPS and SSL
One more solution
Using a Custom Certificate Trust Store on Android
Android: Trusting SSL certificates
others
Any solution didn't work, and I still have "Error: Not trusted server certificate". Maybe You have any idea what I'm doing wrong.
P.S. There are a lot of trust-all 'solutions', but I need proper solution
It is difficult to say exactly why you are having the issue but it sounds like you do not have the private key, the certificate you received from GlobalSign, I presume you generated the CSR? If so you will need to import the .pem file that you received back from GlobalSign the same method, if you did not generate the CSR from a private key within you BKS keystone then it would not be a trusted certificate.
That is what I think is going on anyway
Problem was solved. I have asked technical support of GlobalSign about certificates. They made some tests and took recommendations how to configure certificates on server side. Android part wasn't changed
I hope this isn't a duplicate.
I'm currently working on client server game based on netty with a client on Android. I'm trying to make a secure login process so I tryed using ssl on top of java socket.
I managed to create a self-signed certificate and to use SSL. The problem is that the example source code i found use à custom TrustManagerFactory which doesn't make any check upon certificate validity. Since I don't wan't to allow Man In The Middle attack i searched for more information on SSL handshake and here is what i understood:
To initiate SSL session, the client send a request to the server.
The server which own the certificate(.jks or .bks) extract public informations into a X509 certificate and send it to the client.
The client check for the validity of the certificate ( In my current solution do nothing)
If check succed retrieve the server's public key from the certificate, generate a random key, encrypt it with the public key and sends it to the server.
The server use his private key to decrypt the randomly generated key.
Both client and server now share the same random key and they start a comunication using this key for symetric encryption ( like AES ).
I don't need to accept certificate from anyone else than my own server so i thought about 2 solution:
Save the X509 on client side and create à custom TrustManager witch only accept this certificate. This solution seems easy to implement but rather hard to maintain since every certificate change on server side would need to update X509 certificate on every client.
Create my own CA certificate sign my ssl certificate with this certificate and manage somehow to tel my client to only trust all certificate signed with my CA.
What i understood about CA authentification is this :
A CA root certificate is a normal certificate that contain a key pair.
signing a certificate with a CA mean adding at the end of the being-signed certificate a hash of the whole certificate encrypted with the CA private key.
this signature is contained in the X509 certificate along with some informations about CA.
To check certificate validity, the client generate certificate hash and compare it to the decrypted hash (using CA public key) contained in the X509 certificate.
So if i'm not mistaking in all of this, if i want to implement my second solution, I need to provide a CA certificate to the client so that he can check certificates. I've seen that it is possible to init à TrustManager with a truststore. I asume it must be a different certificate from the root CA one since the whole security of this depends on my CA private key 's confidentiality. So my questions are :
What should this client truststore contain and how to generate if from my root CA ??
I have red that ssl engine is broken for self signed certificate. So is my second solutions viable on android?
If this can work, how can i invalidate my certificate if i see that someone manage to get my private key somehow? I have red things about crl but i don't know how to generate/use them in my truststore?
thanks in advance.
I can only answer part of your questions:
The truststore should contain your CA, you can generate it with keytool:
http://docs.oracle.com/cd/E19509-01/820-3503/6nf1il6er/index.html
No problem you can implement this in android in the same way than in java using java.security.* and org.apache.http.* classes. One warning, for android versions <=2.3, you could need to implement a workaround as some public CA are missing and it doesn't support miss-ordered certificates chains. I can give you more details if needed.
I don't know
Edit:
A good turorial:
http://nelenkov.blogspot.com/2011/12/using-custom-certificate-trust-store-on.html
I have never done https so far, but trying to get grips with it. I understand how to do self-signed certificates which is from what I understood is completely pointless as browsers will fire up straight away the warning. "As one cannot say trust me because I am honest."
From SO posts I understood that Tomcat or any other server environment is responsible for configuration. All clear and good.
The confusion is how these certificate signed when not self-signed. In other words, how do I point my keystore to CA provider.
I am following guide:
http://consultingblogs.emc.com/richardtiffin/archive/2010/10/15/applying-ssl-to-a-spring-web-application-on-tomcat.aspx
The problem is that I don't know what happens after I buy certificate from CA. Do I get a file which I need to point my keystore to or I import keystore itself remotely?
For self-signed we do:
"
Generating a keystore file (Self Certification)
The keystore file is the one which would store the details of the certificates necessary to make the protocol secured, to-do this we'll use the keytool provided as part of JDK 1.6, the following should create the keystore :-
From your Java installation directory %JAVA_HOME%/bin
keytool -genkey -alias emc -keypass password -keystore emc_tomcat.bin -storepass password"
This implies that for not self-signed the details must come from CA provider? So need to add something to the line(URL path?)? Or is it the client responsibility to verify whether my certificate is valid...then how do I link my certificate to the one I purchased. I am completely confused.
Rephrasing other way: how to install CA from official CA providers?
Or I am telling complete rubbish and missing something fundamental. :-)
My apologies if there is duplicate, I've spent quite good bit of time of researching SO and reading wikipedia articles, but the internal mechanics are very difficult for novice users. I've marked bold the actual questions for people short on time. Thanks.
All the information you are asking for is readily provided by any reputable ("trusted") CA. See for example http://www.digicert.com/ssl-certificate-installation.htm
Quoting:
After you create your CSR, purchase your certificate, and the SSL
Certificate validation and processing are complete, you are ready to
install your SSL Certificate(s).
Your certificate will be provided via email or will be available to
download in your DigiCert Management Console. The SSL Certificate is a
text file with encrypted data that your server will use once the
certificate is installed
And following down the Tomcat link:
Tomcat SSL installations can be a bit tricky, but don't worry. Our
knowledgeable support staff is familiar with both the keytool utility
as well as common Tomcat installation methods. We will be happy to
help you generate your Certificate Signing Request (or CSR), install
the certificate to your Java keystore, and configure your server to
use it via either the Tomcat Admintool utility, or by editing the
server.xml configuration file directly.
It seems that this answers all your questions... "buy it and you will see how easy it is".