Say I have the following certification chain
some_company
|______ some_company_technical
|_____________some_cert1
some_cert1 will be replaced every year. By importing the Root certificate and the Intermediate certificate into my client's truststore...
keytool -import -trustcacerts -alias some_company -file some_company.crt -keystore some_client.jks
keytool -import -trustcacerts -alias some_company_technical -file some_company_technical.crt -keystore some_client.jks
...will some_cert1 (and some_cert2, some_cert3 .... some_certn signed the same way) be recognized as a trusted certificates by my application or am I misunderstanding how truststore works ?
As long as the some_certx is signed by the same SubCA/CA, and if these CA certificates are trusted by the client, you should be good, meaning the some_certx will be recognized as trust certificate.
How and Why?
Clients (eg: browser) that communicate with secured servers see if the server's certificate is signed by a CA that the client trusts. If the server's certificate is signed by a CA that client doesn't know about, there is no chain of trust. In simple words, the client doesn't trust the organization (CA) that trusted the server. This is what chain of trust means, do I trust the organization that trusted you? If I trust the organization that trusted you, I can trust you.
You might be thinking what the role of the end-entity (some_certx) would be. The clients have their ways to check the validity and status (revoked or not) of the certificate. The data required for these checks can be found in the end-entity certificate itself. The validity of the certificate can be verified using the Valid from and Valid to fields, and the status of the certificate can be checked using CRL or OCSP. The URLs for these can be found in CRL Distribution Point or Authority Info Access extensions of the certificate.
If either of the 2 above conditions fail, the server cannot be trusted.
Related
I have an existing Server Keystore.
keystore : server_keystore.jks.
alias : abc
CN : DNS1
SAN : DNS1, DNS2, DNS3
Requirement is to replace the self signed cert to CA signed certs.
Now, Another person from my team creates a Keystore for each of the 3 servers.
DNS1.jks
DNS2.jks
DNS3.jks
& creates a cert signing request by generating ".csr" files for each of the DNS.
Now from CA Authority we receive 3 CA signed certificates ".cer" files
I imported all three .cer to server_keystore.jks as trusted ca certs.
root
Intermediate
CA signed DNS1.cer with alias name DNS1
CA signed DNS2.cer with alias name DNS2
CA signed DNS3.cer with alias name DNS3
Q1. Is this valid server Keystore ?
Q2. Can client establish secure connection to my server ?
Q3. How do we replace self signed cert with CA signed cert? Is it with same alias name ?
Got the answer.
1. Its not a valid Server Keystore because self signed key-pair public cert has to be replaced with CA reply public certs.
Then only server can reply with CA signed public certificate & client can validate that CA signed certificate chain to it's known CA roots.
Yes, but you need to share explicitely your server public certs with client & client needs to add your self signed certificate to it's list of trusted certs.
Yes, you need to replace self signed public cert in key pair with CA signed one using same alias name which was used to create the key pair.
Example command:
keytool -importcert -alias -file -keystore .jks -trustcacerts
I have created a SSl certificate using these commands:
openssl genrsa -out kc_ca-key 2048
openssl req -new -out san_domain.csr -key kc_ca-key -config openssl.cnf
openssl x509 -req -days 3650 -in san_domain.csr -signkey kc_ca-key -out kc_ca-cert -extensions v3_req -extfile openssl.cnf
openssl.cnf file contains the common name, country name, subject alternative name and all such information.
In browser, I am able to connect securely after importing this certificate but when i run curl command with same certificate, i get the following error:
NSS error -8156 (SEC_ERROR_CA_CERT_INVALID)
* Issuer certificate is invalid.
* Closing connection 0
curl: (60) Issuer certificate is invalid.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
How to resolve this error
There is not enough information to determine what your problem is.
I am making the following assumptions:
You sent the certificate request (CSR) to a CA provider and got a certificate back.
You setup some sort of web server with that certificate
I am also assuming that you used a "Windows" web browser like IE or Chrome that uses the windows certificate store to test the certificate.
The CA that signed your certificate is a well known CA that has there root certificates in all the common CA Lists.
If the above is true and a web browser like Firefox (that uses it's internal CA list) fails it's because the web server is using a certificate without any intermediate certificates.
You need to go find the intermediate certificates for your CA signed certificate, combine them into a certificate chain and setup your web server with this certificate chain. The details of how to do this will depend on your web server.
Once the web server is setup with a correct certificate chain then your curl command (and firefox) should work fine.
The reason that windows works fine is because windows keeps a list of common intermediate certificates that it can verify a certificate chain with. A openssl based client doesn't, so the intermediate certificates have to come from the SSL socket server (e.g. web server) down to the client to be able to verify the certificate chain back to a trusted root certificate in the client CA list.
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.
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.
After I got certificate, I tried to import it as specified here: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File
But I got this error:
C:\Program Files (x86)\Java\jre6\bin>keytool -import -alias tomcat -keystore C:\ SSL\.keystore -file C:\SSL\SSL_Internal_Certificate_for_isdc-planning.cer
Enter keystore password:
keytool error: java.lang.Exception: Failed to establish chain from reply
I need to import first chain certificate, by apache document
Import the Chain Certificate into you keystore
keytool -import -alias root -keystore <your_keystore_filename> \
-trustcacerts -file <filename_of_the_chain_certificate>
When I printed the certificate it's issuer is:
Issuer: CN=Intranet Basic Issuing CA 2B
I downloaded the chain certificates:
Intranet Basic Issuing CA 1A(1).crt
Intranet Basic Issuing CA 1A(2).crt
Intranet Basic Issuing CA 1A.crt
Intranet Basic Issuing CA 1B(1).crt
Intranet Basic Issuing CA 1B(2).crt
Intranet Basic Issuing CA 1B.crt
Intranet Basic Issuing CA 2A(1).crt
Intranet Basic Issuing CA 2A.crt
Intranet Basic Issuing CA 2B(1).crt
Intranet Basic Issuing CA 2B.crt
Intranet Basic Policy CA(1).crt
Intranet Basic Policy CA.crt
Root CA.crt
Issuer of Intranet Basic Issuing CA 2B.crt is Intranet Basic Policy CA and its Issuer is:Root CA certificate
But I can't import 3 certificates into root alias.
And imported "Intranet Basic Issuing CA 2B.crt" into root and then rerun import of tomcat alias
But got the same error:
keytool error: java.lang.Exception: Failed to establish chain from reply
What is correct way to import correct chain certificate?