Re: Storing TLS credentials in the directory

[Turbo Fredriksson <turbo@bayour.com>]

On 9 Apr 2017, at 17:55, Howard Chu <hyc@symas.com> wrote:

> Turbo Fredriksson wrote:
>> So if I’m understanding this correctly, all you have to do to request
>> a certificate for a specific object, is to read the “userPrivateKey;binary”
>> of that RDN?
> 
> You must request exactly two attributes, otherwise the overlay ignores it:
> 	userCertificate;binary
> 	userPrivateKey;binary

Ah, neat!

The man page states:

    The CA's private key is stored in a cAPrivateKey attribute, and user and 
    server private keys are stored in the userPrivateKey attribute.

so I thought BOTH certs was in userPrivateKey. Which doesn’t make much
sense, in retrospect :)

>>    2) What if I want a new certificate for that RDN?
>>         Such as the previous one is [about to] expire and it needs to be
>>         refreshed (preferably (?) without destroying/removing the old one).
> 
> Currently you would have to delete the old one first.

Ok, thanx. Not that big a’ deal I guess.

>>    3) Is the CAs _public_ key available as well?
>>         Same reason as point 1.
> 
> If the overlay generated it, then it is stored in cACertificate;binary in the suffix entry of the database.

Awesome! Update the man page about this as well then :)

>>    4) If I already have a CA “on premises” and that have created an
>>        intermediate CA I’d like to use for “autoca”, could this be done?
> 
> You can replace cACertificate;binary and cAPrivateKey;binary of the suffix entry to force this.

I see, that’s quite smart! So they’re writable, not just read-only then.
This should probably also be documented.

Is that true for userCertificate and userPrivateKey as well?