Turbo Fredriksson wrote: I've looked at dogtag approx. two years ago. The use of LDAP was, uumh, somewhat strange: dogtag uses (or used?) LDAP server as kind of schema-less database by stuffing arbitrary strings into attribute options / sub-types. So besides the issue you've seen up to now you will run into more quirks. IMHO not worth the effort, but hey, if you want to waste your spare time... Ciao, Michael.

On 27 Mar 2017, at 22:09, Michael Ströder <michael(a)stroeder.com&gt; wrote: Ouch, nah that doesn’t make much sense :(. Do anyone know of any other product/project (open source preferred, but not a requirement) that can do the same - provide certificates programatically?

On 28 Mar 2017, at 15:37, Geert Hendrickx <geert(a)hendrickx.be&gt; wrote: 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.