When creating keystores/truststores, try to name keystores/truststores based on its purpose and whether it is used in a virtualhost or in a target connection.
To easily distinguish keystores and trurststores, the recommendation is if it is used as a keystore, start the names or imbed in the names something like “keystore-” or “ks-” . Apply the same rule to truststores, name them like “truststore” or “ts-”.
Furthermore, try to distinguish keystores/truststores based on its purpose namely where they are used, in a virtualhost or in a target connection. In Apigee Edge, we use terms “inbound/northbound” to represent API traffic going into Apigee, and the configuration for this is in virtual hosts. The terms “outbound/southbound” are used to represent API traffic going to target servers, and the configuration for this is in target servers or .
Therefore, as an example, a keystore used in a virtualhost would start with “ks-ib-”, “ks-nb-”,“keystore-inbound-” or “ks-inbound-”,whereas a keystore used for outbound/southbound would start with “ks-ob-”, “ks-sb-”, etc. Again, apply the same rule to truststores, such as “ts-ob-”, “ts-sb-”, “truststore-southbound”, and so forth.
I also have seen customer added org, env, related information into the name just to further clarify the usage.
Please note that Apigee have introduced keystore and truststore references, please visit our document for references, http://docs.apigee.com/release-notes/content/170508-apigee-edge-public-cloud-release-notes-ui. The above recommendation would also apply when naming a reference in addition to adding “ref-” to the name of a reference. For example, if there is a keystore that is used for inbound connection, ks-ib-api.company.com, then name the keystone reference which references this keystore as ref-ks-ib-api.company.com would be easy for everyone to follow.
What could this approach help? It will come very handy when there are many orgs/envs, virtual hosts, target servers on a complex system and there are needs to set up SSL connections inbound and outbound in virtual hosts, target servers, and different endpoints in different API proxies.
With a better naming convention, it is less likely to specify a truststore when a keystore is needed and vice versa. It is also less likely to specify a wrong keystore or a wrong keystore reference for a given virtualhost or target server definition.