From d2f03f59eadbcc7c5368d1dd02f0e2eac94fa3ed Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Fri, 12 Apr 2013 19:37:20 -0700 Subject: Further clarify the ssl-key Stanford naming policy Adam requested some clarification on whether the name of the object should be fully-qualified or not (since we didn't in the legacy naming scheme). Change-Id: I52fcab71e54aee38f0c03eff774f927c5836ad03 Reviewed-on: https://gerrit.stanford.edu/1054 Reviewed-by: Russ Allbery Tested-by: Russ Allbery --- docs/stanford-naming | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index 81c752c..fa42ee6 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -126,10 +126,13 @@ Object Naming for Apache, Postfix, LDAP, and similar cases where the certificate should match the host name. The public certificate we manage external to wallet since it doesn't need to be protected or - encrypted. here should be the CN of the certificate, - which may be different than the hostname (for hosts with multiple - virtual hosts, for example, or because the certificate is for a - load-balanced name). + encrypted. here should be the fully-qualified DNS name + from the CN of the certificate, which may be different than the + hostname (for hosts with multiple virtual hosts, for example, or + because the certificate is for a load-balanced name). For example, + ssl-key/ldap.stanford.edu for the X.509 private key for the + SSL certificate used across the ldap.stanford.edu load-balanced + pool. An optional component may be added if there are multiple certificates with the same host name as the CN but with -- cgit v1.2.3