Thanks for your help with my last post.
Now, the next task, will be setting up an N-way multimaster: Server1 Server2 Server3 Server4
Using TLS. To create the certificates, finding a lot of varying ideas via google, what is the "best practice" to create certificates to where I don't have to touch each client if a server goes down. Create a wildcard cert or use the subjectAltName in the openssl.cnf file?
John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen@ll.mit.edumailto:john.borresen@ll.mit.edu
On Tue, Jan 14, 2014 at 02:22:53PM -0500, Borresen, John - 0442 - MITLL wrote:
Using TLS. To create the certificates, finding a lot of varying ideas via google, what is the "best practice" to create certificates to where I don't have to touch each client if a server goes down. Create a wildcard cert or use the subjectAltName in the openssl.cnf file?
Is this a public-facing server, or strictly internally facing?
Will you be using an in-house CA?
I'm a fan of an in-house CA (note: note the same as a self-signed cert), and a well-populated SAN list, possibly incorporating IP addresses as well.
John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen@ll.mit.edumailto:john.borresen@ll.mit.edu
These will be self-signed certs. Internally facing servers, approximately 120 to 200 client end-user machines, and 200 to 500 "other" servers.
We, that is my group, does not "own" the facilities domainname (llan.ll.mit.edu); our ldap name is does not have the mit.edu in its name -- long story.
-----Original Message----- From: Brian Reichert [mailto:reichert@numachi.com] Sent: Tuesday, January 14, 2014 2:32 PM To: Borresen, John - 0442 - MITLL Cc: Quanah Gibson-Mount; openldap-technical@openldap.org Subject: Re: N-Way-Multimaster Configuration
On Tue, Jan 14, 2014 at 02:22:53PM -0500, Borresen, John - 0442 - MITLL wrote:
Using TLS. To create the certificates, finding a lot of varying ideas via google, what is the "best practice" to create certificates to where I don't have to touch each client if a server goes down. Create a wildcard cert or use the subjectAltName in the openssl.cnf file?
Is this a public-facing server, or strictly internally facing?
Will you be using an in-house CA?
I'm a fan of an in-house CA (note: note the same as a self-signed cert), and a well-populated SAN list, possibly incorporating IP addresses as well.
John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen@ll.mit.edumailto:john.borresen@ll.mit.edu
On Tue, Jan 14, 2014 at 03:09:43PM -0500, Borresen, John - 0442 - MITLL wrote:
These will be self-signed certs. Internally facing servers, approximately 120 to 200 client end-user machines, and 200 to 500 "other" servers.
We, that is my group, does not "own" the facilities domainname (llan.ll.mit.edu); our ldap name is does not have the mit.edu in its name -- long story.
Do you mean that you'll be accessing these hosts using non-fully qualified hostnames? (e.g. 'server1.llan.ll' or 'server1' ?) If so, you can put these names in the SAN list. You can put IPs in there, too, but MS wants special treatment for that...
Really, though, as you're doing this all privately, you need to consider:
- How often would the membership of your cluster change (adding/removing hosts)?
- How are you distributing the trust of the signer? One CA means your clients only need to be told once about the signer, and self-signed means your clients needs to be told about each cert. (Well, each signer, but sounds like it's implicitly fluid, given the prior question.)
If - cluster membership will change - you don't want to touch each client when that happens - you're using non-fully qualified hostnames
The I think you'll benefit from a CA, rather than self-signed certificates.
That doesn't address wildcard vs a SAN list. Can you forecast that the current and future hostnames for your cluster will always be expressible as a wildcard? If not, consider a SAN list.
Borresen, John - 0442 - MITLL wrote:
Thanks for your help with my last post.
Now, the next task, will be setting up an N-way multimaster: Server1 Server2 Server3 Server4
Using TLS. To create the certificates, finding a lot of varying ideas via google, what is the "best practice" to create certificates to where I don't have to touch each client if a server goes down. Create a wildcard cert or use the subjectAltName in the openssl.cnf file?
Personally I' prefer to issue separate certs to each replica. I use the server certs also as client cert for authenticating the replicas to each other with SASL/EXTERNAL.
Ciao, Michael.
"Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu schrieb am
14.01.2014 um 20:22 in Nachricht 201401141923.s0EJNERG089333@boole.openldap.org:
Thanks for your help with my last post.
Now, the next task, will be setting up an N-way multimaster: Server1 Server2 Server3 Server4
Using TLS. To create the certificates, finding a lot of varying ideas via google, what is the "best practice" to create certificates to where I don't have to touch each client if a server goes down. Create a wildcard cert or use the subjectAltName in the openssl.cnf file?
Hi!
I don't see your problem: The certificates are just "normal"; one for each server. And you want to add each server to each client. If one server goes down, you don't have to do anything. What did I miss from your description?
Regards, Ulrich
John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen@ll.mit.edumailto:john.borresen@ll.mit.edu
openldap-technical@openldap.org
-
Borresen, John - 0442 - MITLL -
Brian Reichert -
Michael Ströder -
Ulrich Windl