Martín Coco wrote:
I've not read the book. Maybe I can nevertheless give you some helpful hints.Hi,[...] I've been reading the man for OpenSSL, this mailing list, and also acquired the book "Planning for PKI".
Hard to say. This would strongly depend on how your company is organised. From what you write I'd assume it is a bigger, probably international organisation. If this is not the case I'd just generate a single subCA that does all the work.My main goal is to design a PKI for our server infrastructure (ldaps, https, mail, vpn, etc.) The problem is that, for example, when reading the mentioned book, all the examples are based on people, but not on systems or services. So you have all these divisions by locality, department, etc, but always based on people. I was thinking of building a hierarchical PKI in which I had the root ca, and then a subCA for each of the needed services. This last CA would be responsible to generate and sign certificates for each server related to the service it provides. So, for example, the subCA for LDAP would sign certificates for our master LDAP server, the slave LDAP server, and so on.Does this make sense?
In a big organisation I'd try to mirror the existing administrative structures. If you have a department managing all the LDAP servers all over the world and another doing all the mail servers there should be a special LDAP-CA and a special mailserver-CA, as you proposed it. If it's more like one department managing all german servers and another one managing the french ones, I guess it would make more sense to generate a "German Servers CA" and a "French Servers CA"...
If the certificates should be usable for external mails company CA signed certificates are not the ideal solution, since probably your company's CA certificate is not known by most external mail recipients. For this reason I'd prefer certificates signed by "well known CAs" for email authentication.If I also wanted to generate and sign certificates for people to use in their mail, should I place them in this PKI architecture, or create another one altogether? Should I place them in mail service tree of this architecture?
Usually the person only knows/trusts the root CA and the server sends the subCA's certificate during the handshake as a chained cert. This is sufficient to trace a reliable path to the root CA's certificate. Of course it would also be possible to distribute all subCA certs, but it doesn't really make much sense.Also, if a person connecting to one of these servers were to authenticate it, it should have the subCA's certificate and the root CAcertificate to validate the certification path, right?
That would mean that every person should have a certificate for each subCA or service they want to check, and the root CA. Is this correct?
No. See above. The root certificate is enough.
How does all this sound to you? Whenever I try to look for examples, all I find is based on people, or very specific examples. I'll appreciate any comments on this. Thanks, Martín.
Hope it helps, Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26
smime.p7s
Description: S/MIME Cryptographic Signature
