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 :)
- 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.
- 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 :)
- 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?