I’m trying to implement Dogtag (http://pki.fedoraproject.org/wiki/PKI_Main_Page) with my existing OpenLDAP/MIT Kerberos V installation (that’s been running for years).
But it’s failing because of:
[27/Mar/2017:15:49:17][http-bio-8443-exec-3]: confirmMappings: Checking other subtrees using database Domain.TLD-CA. [27/Mar/2017:15:49:17][http-bio-8443-exec-3]: populateDB: netscape.ldap.LDAPException: error result (32); matchedDN = cn=config [27/Mar/2017:15:49:17][http-bio-8443-exec-3]: Error in populating database: Failed to check database mapping: netscape.ldap.LDAPException: error result (32); matchedDN = cn=config
Dogtag is only (officially) supporting 389ds, but installing (and maintaining!) another LDAP/Krb5 server(s) on the network just seems … “wrong”! :)
The code looks like:
https://github.com/dogtagpki/pki/blob/DOGTAG_10_2_6_BRANCH/base/server/cms/s...
Basically, it looks for “nssldap-backend=Domain.TLD-CA” below “cn=mapping tree,cn=config” (which don’t exists in OpenLDAP of course).
Is there any “389ds compatibility module” or possibly a DN rewrite hack I could use for this? I’ve never used “389ds” before, so I’m unsure what that object is supposed to look like, or what “cn=mapping tree” is for exactly..
Turbo Fredriksson wrote:
I’m trying to implement Dogtag (http://pki.fedoraproject.org/wiki/PKI_Main_Page) with my existing OpenLDAP/MIT Kerberos V installation (that’s been running for years).
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.
Dogtag is an appealing solution when a fully fleshed PKI is needed.
But do NOT try to remove its internal DB. This will not work. Discussed with the implementors hundreds of time.
Dogtag has a notion of "publishing directory" (distinct from its internal DB), which can be openldap. This is where should be the junction IMO.
Le 27/03/2017 à 23:09, Michael Ströder a écrit :
Turbo Fredriksson wrote:
I’m trying to implement Dogtag (http://pki.fedoraproject.org/wiki/PKI_Main_Page) with my existing OpenLDAP/MIT Kerberos V installation (that’s been running for years).
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@stroeder.com wrote:
I've looked at dogtag approx. two years ago. The use of LDAP was, uumh, somewhat strange:
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 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.
https://www.openca.org/ https://en.wikipedia.org/wiki/OpenCA
Geert
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.
openldap-technical@openldap.org