9:55 a.m.
Turbo Fredriksson wrote:
On 9 Apr 2017, at 14:24, Howard Chu <hyc(a)symas.com> wrote:
> Please read the slapo-autoca(5) manpage for more info.
This is exactly how easy I’m envisioning this to be! Brilliant, thanx!
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
Now, I know it’s well to early for feature requests :D, but I have a
few
questions (and a feature request :):
1) Why is both certificates (private AND public) in the same attribute?
I can see the reason to have the public … “public” (with a much
more relaxed ACL/ACI).
They aren't, they are in two separate attributes.
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.
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.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:24 a.m.
New subject: Storing TLS credentials in the directory
On 9 Apr 2017, at 17:55, Howard Chu <hyc(a)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?
2177
days inactive
2177
days old
1 comments
2 participants
participants (2)
-
Howard Chu -
Turbo Fredriksson