On 9 Apr 2017, at 17:55, Howard Chu <h...@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?
