[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Dogtag CA with OpenLDAP?
- To: openldap-technical@openldap.org
- Subject: Re: Dogtag CA with OpenLDAP?
- From: Turbo Fredriksson <turbo@bayour.com>
- Date: Thu, 6 Apr 2017 10:49:27 +0100
- Authorized-sender: turbo@bayour.com
- In-reply-to: <20170328143719.GA31945@vera.ghen.be>
- References: <C1173D86-0979-4E98-B67C-286B6FBAD02B@bayour.com> <02c07d0d-2979-c528-a239-acd64a3428a7@stroeder.com> <57460F4A-501D-4839-9779-E307FE4EA5B0@bayour.com> <20170328143719.GA31945@vera.ghen.be>
On 28 Mar 2017, at 15:37, Geert Hendrickx <geert@hendrickx.be> wrote:
> On Mon, Mar 27, 2017 at 22:17:50 +0100, Turbo Fredriksson wrote:
>> Do anyone know of any other product/project (open source preferred, but not
>> a requirement) that can do the same - provide certificates programatically?
>
> We used OpenCA for SCEP with Cisco routers, but it seems no longer maintained.
Thanx, I’ve been looking into that and there are … “spinoffs” that could possibly do
the job (although OpenCA seems workable even if it haven’t been updated in a few
years), but they’re all very complex (comes with the territory I guess).
I’ve decided on a workaround. It’s not pretty and I’m not happy with it, but it “kinda” works.
This will have to do for now, until I have more time to play with this.
For posterity, if anyone is interested:
I’m using my own, self-signed, OpenSSL CA (with a script that creates the host certs
and can “convert” the certs to OpenTLS when/where needed) which is an offline thing.
I just copying the public key to the puppetry (to a private repo, with very limited access,
but that’s ok - it’s the public key any way) and then inserts the private key into a Hiera
key and encrypt it with eyaml.
I use Hiera/eyaml from puppet to encrypt the private key and each environment have
their eyaml keys in the (new) “Parameter Store” (a key/value store in AWS basically)
in AWS. Each environment have their own encryption key to decrypt the parameter.
Each of those [“Parameter Store”] encryption keys are tied into a AWS Role, which in
turn is “connected” (?) to an instance profile.
So instances can only retrieve the “Parameter Store” values dependent on the profile
(and therefor Role) it’s started with and those roles dictate what “Parameter Store”
key/values that role have access to (such as “allow decrypt of keys like ’test.*’” or
“allow decrypt of keys like ‘demo.*’” etc).
So the bootstrap script [for the instance] retrieves the eyaml keys from the “Parameter Store”,
“using" the instance profile and Role, then those eyaml keys allow puppet to decrypt
the Hiera/eyaml encrypted keys, such as the Hiera/eyaml private key value of the
certificate for that instance (technically, for that environment).
So, there’s still a “blast radius” (I’m doing this on the environment basis, a “collection”
of hosts), but it’s way, way smaller this way.
In some cases, I’ve have the instance profile, Role and “Parameter Store” in such a way
that one _type_ of instance (such as an LDAP or KerberosV server) have their own,
unique, setup like this, minimising the blast radius for those services to a bare minimum.