I am trying to set up 2 way ssl mutual authentication for my web application. I currently haven't set up my client and am testing my web service through my browser.
I created a client certificate using the keychain tool on my mac and import the certificate.p12 file in Firefox. I also have a certificate.cert file. From my understanding I need to add this cert file in my servers truststore.
For that I need to using the following command:
keytool -import -trustcacerts -alias <hostname of DP> -file <your file.crt> -keystore <truststorefile>
However what do I add as the hostname of my system? What will the browser show the hostname as to my webserver?
First if you have client cert(s) issued by either a well-known CA (like Verisign, GoDaddy, etc) or a locally-trusted one (like your employer), you don't have to do anything. The client will simply present the cert with a chain that leads to the already-trusted CA.
If you have issued client certs from your own CA, you should add the CA (root) cert only to the server truststore. Then all client certs issued by that CA will be validated without further effort. If you make the CA cert long-lived, as is the usual practice, you can even renew and/or replace client certs with no effort on the server. And you can automatically revoke them if you set up CRL distribution and/or OCSP, although DIY CAs don't always want to go to that effort.
If you have created a self-signed client cert, then and only then you need to add that specific cert to the server truststore. Although SSL/TLS server certs must be identified by the hostname(s) of the server, client certs are not required to, and CA certs (which are the certs usually in your truststore by default) never have a hostname as the Subject (although some extensions usually contain URLs that contain hostnames). Codesigning certs also don't need to use a hostname.
The alias of a cert entry in a Java truststore does not need to be the hostname; it only needs to be unique, although it should be mnemonic of the subject of the cert. If for example your client certs are for users named Alice and Bob (or more likely their PCs or whatever devices) you can just use alice and bob as the aliases.
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
I have to create an SSL connection between a client and a server. I've created a keypair and signed my public key with my private key. The server won't trust this so I need to get it signed by a CA. I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate. How do I do the business of creating the signed certificate with keytool? Sorry if this is duplicated information on the Oracle website, but for some reason their pages keep breaking my internet browser.
knowledge so far is based on answer here
I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate.
Correcting your assumption here: A system trusts various major Certificate Authorities (CA) by default (eg: GeoTrust, Entrust, OpenTrust, Verisign, etc...). When you get your CSR signed by any of these known CA's, the server will trust by default, not just by the CA that signed the server's certificate.
What you could do to test your SSL connection between the client and the server is to work with self-signed certificates.
I've created a keypair and signed my public key with my private key
You shouldn't be doing this as a client. The server is supposed to do this. If the server is working with self-signed certificates, they need to provide the client with that certificate, so that the clients can trust them to make the SSL connection.
As a server, you could use the keytool to create a self-signed certificate. When you are generating a keypair using keytool, it will ask you few attributes like commonName, organizationName, etc... using these attributes, the keytool will create a self-signed certificate and associate it with the private key. All you have to do is export this certificate using the keytool -exportcert command. Once you have done this part, you would use this certificate to secure the server.
Once the server is secured, the server should give or the client this certificate, because it is self-signed and the client's system will not trust it until you explicitly trust it. If the server has secured using a certificate signed by a CA, it need not provide the client with any certificate, because, if it is a known CA, it will already be trusted by the client system.
According to https://wiki.jasig.org/display/CASUM/X.509+Certificates,
After the Server sends the certificate that identifies itself, it then can then send a list of names of Certificate Authorities from which it is willing to accept certificates.
I am wondering how to determine what this list is, and how to modify it.
The reason I am asking is that I am getting an infinite redirect between my server and my client after successful validation (i.e., the ticket stage), and I think it has to do with the CAS server not recognizing the CAS client's certificate (the client's certificate is self-signed).
If you want to see what this list is, you can use OpenSSL:
echo "" | openssl s_client -connect your.server:port
This will show various messages regarding the handshake, including the certificates and the list of CAs in the CertificateRequest message.
Ultimately, it's determined by the active X509TrustManager's getAcceptedIssuers() method. By default, this will be the list of Subject DNs of all your trust anchors (that is, the Subject DNs of all the certificates in your trust store).
Your client certificate will have to be verified by the server. This is normally done during the handshake by the trust manager, which (unless tweaked) will build a chain to a known CA (or at least known cert if it's the user cert itself) in the trust store.
Adding your self-signed certificate to your trust store should be sufficient. It doesn't have to be the cacerts file bundled with the JVM, you could make a copy of it and use the trust store settings of Apache Tomcat's connector to set it up.
I have three files from Entrust: *.csr, *.key and *.crt.
So far:
I have brought the *.key and *.crt into a PKCS12 keystore using OpenSSL
I have imported the *.pkcs12 into a keystore using keytool
Using this technique, I am able to use an SSL connection with Jetty
However, I'm getting a Certificate Error in IE (unsecured items in Chrome).
In our case, the certificates are currently being used for domain:80 (Apache) and I'm attempting to "reuse" them for domain:8443 (Jetty).
Am I wrong in thinking that I can use these for Jetty as well? On the same IP/domain, but on a different port and webserver? My gut is telling me that one of these files relates to Entrust recognizing Apache (*.csr) and that I should have to do the same for Jetty?
Edit #1
The error goes as follow:
Certificate Error
Untrusted Certificate
The security certificate presented by this webiste was not issued by a trusted certificate authority
This problem may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage.
But yet Chrome, sees it as valid. I does have to work on IE since it's our standard.
Edit #2
Chrome doesn't complain
Nor does Firefox
Edit #3
I found our CA certificate specified in the Apache conf file. I then proceeded to concatenate our cert with the CA cert into a PKCS12 file. Then, using keytool, I generated the keystore.
I loaded it on the server, rebooted and viewed in IE. IE still shows a certificate issue.
In the concatenated file, I see in this order: our cert and then 2 other certificates.
On a side note, I called Entrust and the CSR saw no problems as he was using IE 8. We're on IE7.
Edit #4
Using this command:
keytool -list -keystore keystore -v
It shows 3 certificates (in this order):
Ours
Owner: CN=Entrust Certification Authority - L1C,
Owner: CN=Entrust.net Certification Authority (2048)
Edit 5
Solved! I guess I had a caching issue. Confirmed with colleagues.
Answer, Concatenating all my certs, including the CA cert, into the keystore solved my issue.
The port number, as stated in the comments, is irrelevant for trusting an SSL/TLS connection.
The problem is that the entire certificate chain from your certificate up to the Entrust root probably looks like this
your cert - intermediate CA 1 - intermediate CA 2 - ... - root CA
To make this work for IE you have to import not only your certificate into the PKCS#12 container, but additionally the intermediate certificates and also the root certificate. Otherwise your SSL implementation won't be able to provide the full path during the SSL handshake and thus IE has no means to build a proper chain to compare to its set of trusted root certificates.
So my advise would be to get the intermediate certificates from the appropriate web sites and importing them with keytool into your PKCS#12 key store.
Once done, IE should from then on accept without complaining.
I'm trying to configure Apache Tomcat to use SSL connection with client authentication (two way authentication). My certificates are CA signed.
If I put CA certificate, together with client certificates, in tomcat truststore everything is OK. If I don't put CA cert in tomcat truststore, Tomcat won't trust to clients.
Do I need CA certificate in tomcat truststore?
If I put CA certificate in truststre then Tomcat will trust to every client that have certificate signed by the same CA.
Yes, you need the CA in the truststore. If you are unwilling to put the CA in the truststore, you should not use the CA.
Regarding your last paragraph, you could also examine the Distinguished Name of the client certificates for further authorization.
You are confusing trust, or authorization, with authentication. The only purpose of SSL certificates is to prove that the peer is who he says he is, i.e. establish his identity. You need to decide whether or not you trust that CA's procedures for verifying identity prior to signing CSRs, and if so put its certificate into the truststore.
Whether you want that identity to access parts of your system is a completely different question which you must solve in a different way, via a database of roles granted to identities. This is something that LDAP is particularly good at, but you can also use a DBMS or even an XML file in Tomcat. Have a look at Tomcat Realms for how to do this.
What you mustn't do is attempt to use the truststore as that database. That's not what it's for, and not the purpose for which it or PKI was designed. Which is why you're having problems trying to use it that way.