SSL certs location

reference　：https://serverfault.com/questions/62496/ssl-certificate-location-on-unix-linux

1 . This will vary from distribution to distribution.

For example, on Amazon Linux instances (based on RHEL 5.x and parts of RHEL6, and compatible with CentOS), the certificates are stored in /etc/pki/tls/certs and the keys are stored in /etc/pki/tls/private.

The CA certificates have their own directory, /etc/pki/CA/certs and /etc/pki/CA/private.

For any given distribution, especially on hosted servers, I recommend to follow the already-available directory (and permissions) structure, if one is available.

2. This is where Go looks for public root certificates:

"/etc/ssl/certs/ca-certificates.crt",                // Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt",                  // Fedora/RHEL 6
"/etc/ssl/ca-bundle.pem",                            // OpenSUSE
"/etc/pki/tls/cacert.pem",                           // OpenELEC
"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
"/etc/ssl/cert.pem",                                 // Alpine Linux

Also:

"/etc/ssl/certs",               // SLES10/SLES11, https://golang.org/issue/12139
"/system/etc/security/cacerts", // Android
"/usr/local/share/certs",       // FreeBSD
"/etc/pki/tls/certs",           // Fedora/RHEL
"/etc/openssl/certs",           // NetBSD
"/var/ssl/certs",               // AIX

3.If you are looking for a certificate used by your Tomcat instance

1. Open the server.xml file
2. Search for SSL/TLS connector
3. See keystoreFile attribute that contains the path to keystore file.

It looks like

============================

SSL handshake: 

To explain in common usecase/purpose or layman way:

TrustStore : As the name indicates, its normally used to store the certificates of trusted entities. A process can maintain a store of certificates of all its trusted parties which it trusts.

keyStore : Used to store the server keys (both public and private) along with signed cert.

During the SSL handshake,

1. A client tries to access https://

2. And thus, Server responds by providing a SSL certificate (which is stored in its keyStore)

3. Now, the client receives the SSL certificate and verifies it via trustStore (i.e the client's trustStore already has pre-defined set of certificates which it trusts.). Its like : Can I trust this server ? Is this the same server whom I am trying to talk to ? No middle man attacks ?

4. Once, the client verifies that it is talking to server which it trusts, then SSL communication can happen over a shared secret key.

Note : I am not talking here anything about client authentication on server side. If a server wants to do a client authentication too, then the server also maintains a trustStore to verify client.

https://stackoverflow.com/questions/6340918/trust-store-vs-key-store-creating-with-keytool/6341566#6341566