Java 1.5 added an enhancement to support signature timestamps. The idea, as far as I can tell, is that signed jar files should not become invalid just because the code signing certificate has expired, as long as the files were signed while the certificate was valid. In theory, this means we do not have to re-sign and redeploy our applications every year when the certificate expires. Unfortunately, there seem to be problems in the implementation, based on these two forum threads:
http://forums.sun.com/thread.jspa?threadID=744677
http://forums.sun.com/thread.jspa?threadID=5309004
I'm about to begin testing this, but I was wondering if anyone has successfully done this, without having to import the timestamping certificate on the client (which would defeat the whole purpose)?
The Thawte TSA root certificate was added to Sun's JRE cacerts file in 6u10 and 5.0u18.
Unfortunately, this feature appears to be completely worthless at this time. It is easy to add a timestamp when signing a jar file, just add this parameter to the jarsigner command:
-tsa https://timestamp.geotrust.com/tsa
This is the URL to Thawte's timestamping server. Unfortunately, the Thawte timestamping CA cert is not included in the Java runtime's list of trusted CA certs, so it is effectively meaningless. That is, if you load the applet after the code signing certificate has expired, you get the "untrusted" warning dialog instead of the "trusted" one.
There is a "workaround", of sorts, posted here, but it works by embedding the Thawte timestamping CA cert in the applet itself, and running keytool on the client to import the cert. I can't see how this would work though, since the user will already have seen the signed code dialog before this code can run.
I'll keep looking for a solution, but I'm not hopeful. I can't imagine why a usable timestamping CA cert has not been included with the Java runtime after all this 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 bought a COMODO code signing certificate and used it to sign my java webstart application.
Main question: Is that COMODO code signing certificate even supported by java 8?
More info:
On all machines except my own, java blocks the application, saying it uses a self signed certificate.
I don't even understand why it works on my machine. I looked at the list of trusted certification roots in the java control panel (1.8.0_45-b15), but I cannot find the "COMODO RSA Certification Authority" there.
I do see that certificate in the Windows MMC certificate snap-in under "Trusted Root Certification Authorities". But on at least 3 other machines it does not exist.
I finally solved it - here is the story:
When I bought the certificate, I had to collect it by navigating to a website address that I received by email. There, the certificate was automatically installed into the truststore of my browser (Firefox).
I then exported it from Firefox (Options - Advanced - View Certificates - Your Certificates - Backup button).
What I didn't realize at the time was that Firefox, unlike Java and Windows, has the "COMODO RSA Certification Authority" as an inbuilt token:
What I also didn't know at the time was that the Firefox certificate export seems to only include the certificate chain up to the first trusted authority, in this case the "COMODO RSA Certification Authority".
From this COMODO support site I learned that the chain should actually go one higher, all the way up to "AddTrust External CA Root":
That sounded much more promising, because the AddTrust certificate is actually included in Oracle's java 8 cacerts truststore, which is responsible for verifying the jar during java webstart.
The next thing I did was import the *.p12 file I got from Firefox into the windows certificate manager (Start - certmgr.msc), because for some reason I thought this was the way to convert *.p12 to *.pfx (although now I know that both extension are used for the same pkcs12 keystore format). Anyway, during the import this question popped up:
Here I made the critical mistake: I clicked yes. This caused the "COMODO RSA Certification Authority" to be installed in the Windows truststore as a "Trusted Root Certificate" (btw only visible after I restarted certmgr.msc):
My code signing certificate was installed in "Personal/Certificates". I exported it from there (Action - All tasks - Export...), and marked "Include all certificates in the certification path if possible".
Now the exact same thing happened as when I exported from Firefox. Since Windows now had "COMODO RSA Certification Authority" installed as a trusted root certificate, it only included the chain up to this one. This is what I got after the export:
And now for the genius move, which I stumbled upon by pure chance: I deleted the "COMODO RSA Certification Authority" from the Windows certification manager. Now, when I double clicked my code signing certificate, the displayed chain suddenly looked different:
I admit I got a small adrenaline rush when I saw this. I exported again (exact same settings as before).
And indeed, after I signed my application with this exported certificate, java webstart accepts it:
UPDATE: This was a JRE release bug. Comodo's new CA certs were added to the default keystore in Java 8u51.
An answer to another question which while somewhat out of place there seems very on topic here:
You can tell if a CA's certs will work for Java code-signing by
examining the Java cacerts file, which lists all the CAs known to
Java. If their cert is in this file, then Java will not complain about
the signed code. If it isn't, then it will warn the users. For
example:
root#girflet:~# keytool -list -keystore
/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/security/cacerts | grep
comodo
Enter keystore password: changeit
comodoaaaca, 02-May-2006, trustedCertEntry,
Note that I had to enter the default keystore password, changeit.
This command should work on Windows as well, although you'll have to
change the path to the cacerts file and you won't have grep. Use more
instead and page through until you find or don't find what you're
looking for.
As of today, Comodo is in the cacerts file, and startssl aren't. So a
startssl cert wouldn't be much good for Java code.
Source: https://stackoverflow.com/a/1906679/154527
I can give you a conditional answer.
On one of the computers that doesn't like your certificate, go to http://jonathancrosmer.com/software/invadeearth/
and click Invade Earth.
This program uses a Comodo certificate. I built it against Java 7, but if your computer has only a Java 8 runtime it should still work.
1. If you get the same warning, you know it is a Java 8 issue.
2. Otherwise, you know something is wrong with your certificate.
Either way, you'll probably want to get a refund from your certificate issuer, since they advertise that their certificate is trusted by Java.
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".
I am building a simple app monitor to poll one of our API URLs and email us if it can't get a HTTP 200 status code from the response (this would indicate our API is down for some reason).
I am using HttpClient 4.1 (this is important because its API differs greatly from 3.x).
Our API is secure with SSL, however entering:
http://example.com/our-api
into a web browser redirects you to
https://example.com/our-api
Without causing any errors.
When HttpClient attempts to hit this URL (http://example.com/our-api), it fails with a javax.net.ssl.SSLPeerUnverifiedException exception with a message stating:
peer not authenticated
I see this happening a lot for other people as is evidenced by this post (which also provides some ways of circumventing this problem - a solution that I am going to try and implement tonight in fact).
What this other post (and the other similar ones to it) do not do is explain why this is happening in the first place! So, rather than ask "how do I fix this?" I figured I would ask "why is this happening?" Before I go barging ahead with one of the proposed solutions, I'd like to know what the problem is that I'm attempting to fix ;-)
If the server's certificate is self-signed, then this is working as designed and you will have to import the server's certificate into your keystore.
Assuming the server certificate is signed by a well-known CA, this is happening because the set of CA certificates available to a modern browser is much larger than the limited set that is shipped with the JDK/JRE.
The EasySSL solution given in one of the posts you mention just buries the error, and you won't know if the server has a valid certificate.
You must import the proper Root CA into your keystore to validate the certificate. There's a reason you can't get around this with the stock SSL code, and that's to prevent you from writing programs that behave as if they are secure but are not.
This is thrown when
... the peer was not able to identify itself (for example; no
certificate, the particular cipher suite being used does not support
authentication, or no peer authentication was established during SSL
handshaking) this exception is thrown.
Probably the cause of this exception (where is the stacktrace) will show you why this exception is thrown. Most likely the default keystore shipped with Java does not contain (and trust) the root certificate of the TTP that is being used.
The answer is to retrieve the root certificate (e.g. from your browsers SSL connection), import it into the cacerts file and trust it using keytool which is shipped by the Java JDK. Otherwise you will have to assign another trust store programmatically.
keytool -import -v -alias cacerts -keystore cacerts.jks -storepass changeit -file C:\cacerts.cer
Im not a java developer but was using a java app to test a RESTful API. In order for me to fix the error I had to install the intermediate certificates in the webserver in order to make the error go away. I was using lighttpd, the original certificate was installed on an IIS server. Hope it helps. These were the certificates I had missing on the server.
CA.crt
UTNAddTrustServer_CA.crt
AddTrustExternalCARoot.crt
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.