[PATCH] pki-cfu-0090-Ticket-1531-Directory-auth-plugin-requires-LDAP-anon.patch
by Christina Fu
This patch is for ticket
https://fedorahosted.org/pki/ticket/1531 Directory auth plugin requires
LDAP anonymous binds
This patch adds a feature to allow a directory based authentication
plugin
to use bound ldap conneciton instead of anonymous.
Two files need to be edited
1. <instance>/conf/password.conf
add a "tag" and the password of the binding user dn to the file
e.g. externalLDAP=password123
2. <instance>/ca/CS.cfg
add the tag to cms.passwordlist:
e.g. cms.passwordlist=internaldb,replicationdb,externalLDAP
add the prefix of the auths entry for the authentication instance
e.g. externalLDAP.prefix=auths.instance.UserDirEnrollment
add relevant entries to the authenticaiton instance
e.g. auths.instance.UserDirEnrollment.ldap.ldapBoundConn=true
auths.instance.UserDirEnrollment.ldap.ldapauth.authtype=BasicAuth
auths.instance.UserDirEnrollment.ldap.ldapauth.bindDN=uid=rhcs,ou=serviceaccounts,dc=EXAMPLE,dc=com
auths.instance.UserDirEnrollment.ldap.ldapauth.bindPWPrompt=externalLDAP
The code has been tested to work.
The code (in its plugin form) has also been tested to work successfully
with an ldap server that has its anonymous bind turned off.
thanks,
Christina
9 years, 1 month
PKIConnection cert validation #1253
by Christian Heimes
Hi,
this mail is about my take on issue https://fedorahosted.org/pki/ticket/1253
Yesterday night I had a long conversation with Ade on #dogtag-pki. He
explained the install process in great detail to me. Thanks Ade! :) Do
we have a logging bot in the channel or another way to store discussions
for the future?
Today I took the scenic route and explored the implementation of
pkispawn as well as how it interacts with Tomcat over HTTPS. Ade already
pointed three distinct cases. There might be a couple more case, though.
I haven't tried them all yet.
Case #1: creation of security domain
------------------------------------
The first case occurs during the initial installation of the security
domain, when no CA cert is imported. During the installation pkispawn
setups up a Tomcat instances and creates a CA. Because no CA exists in
the beginning of the process, the installer uses a temporary self-signed
cert for the Tomcat server instance. The self-signed cert is stored in
PKI's NSS database. The name of the certificate for instance
'pki-tomcat' is 'Server-Cert cert-pki-tomcat'. This certificate is used
throughout the entire installation until Tomcat is restarted.
# certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-tomcat CTu,Cu,Cu
# certutil -d /etc/pki/pki-tomcat/alias/ -L \
-a -n 'Server-Cert cert-pki-tomcat' | openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=2015-08-05 14:11:10, CN=vm-089.example.com
Validity
Not Before: Aug 5 12:13:05 2015 GMT
Not After : Aug 5 12:13:05 2016 GMT
Subject: O=2015-08-05 14:11:10, CN=vm-089.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
After pkispawn has successfully spawned the CA, the trust anchor is
available in NSS database, too. Its name is 'caSigningCert
cert-pki-tomcat CA' for 'pki-tomcat'. 'Server-Cert cert-pki-tomcat' is
replaced with a signed cert.
# certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-tomcat CA CTu,Cu,Cu
Server-Cert cert-pki-tomcat u,u,u
auditSigningCert cert-pki-tomcat CA u,u,Pu
ocspSigningCert cert-pki-tomcat CA u,u,u
subsystemCert cert-pki-tomcat u,u,u
# certutil -d /etc/pki/pki-tomcat/alias/ -L -a -n \
'caSigningCert cert-pki-tomcat CA' | openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=example.com Security Domain, CN=CA Signing Certificate
Validity
Not Before: Aug 5 12:26:52 2015 GMT
Not After : Aug 5 12:26:52 2035 GMT
Subject: O=example.com Security Domain, CN=CA Signing Certificate
# certutil -d /etc/pki/pki-tomcat/alias/ -L -a -n \
'Server-Cert cert-pki-tomcat' | openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=example.com Security Domain, CN=CA Signing Certificate
Validity
Not Before: Aug 5 12:26:52 2015 GMT
Not After : Jul 25 12:26:52 2017 GMT
Subject: O=example.com Security Domain, CN=vm-089.example.com
Case #2: new subsystem on the same host
---------------------------------------
For new subsystems on the same host, pkispawn simply has to trust the CA
Signing Certificate from #1. The same is true for the 389-DS server cert.
Case #3: subsystem on different host
------------------------------------
When a new subsystem is installed on a different host, the user must
provide the trust anchor for 389-DS out-of-band. A user could also use
plain LDAP, but let's not go there. The trust anchor for the LDAP cert
might be the same as the trust anchor for the security domain -- or it
might be a different one. In both cases it's probably easier to grab the
trust anchor from LDAP. The LDAP connection is set up before pkispawn
does the first HTTPS request.
Case #4: clone on different host
--------------------------------
For installations of a clone or subsystem, the trust anchor must be
provided out-of-band. For a cloning setup
http://pki.fedoraproject.org/wiki/Cloning_Setup the PKCS#12 file should
contain all necessary information. It might also be possible to grab the
cert from LDAP like in case #3.
Case #5: security domain with imported CA
-----------------------------------------
I haven't tried to configure a CA with an externally managed and
imported trust anchor yet. Does anybody happen to know the nickname of
the cert and its trust anchor?
Conclusion
==========
In case #1 pkispawn should dump the self-signed cert from NSS DB to PEM
file. requests can then load the self-signed cert as CA cert. For
self-signed certs this makes the cert trusted. The file should be
removed at the end of the installation.
In case #2 pkispawn should dump the trust anchor from the NSS database
to a PEM file, too. I suggest to put the PEM file in a location where it
can be read by everybody. /etc/pki/pki-tomcat is only accessible by root
and members of the pkiuser group. It has no X bit for other.
In case #3 the cert must either be provided out-of-band or grabbed from
LDAP. I like the idea to grab it from LDAP and have an official API to
do so. Other systems like FreeIPA could use the same API, too. Like in
case #2 the cert should be dumped to a public-readable location.
We could handle case #2 and #3 the same way and always grab the trust
anchor from LDAP. It's less code and more robust, too.
Open question
-------------
1) Is there a stable and easy way to find the trust anchor in LDAP? In
my test setup the trust anchor has subjectName='CN=CA Signing
Certificate,O=example.com Security Domain'. Is the name always similar?
2) Does anybody know how case #5 affects the nickname or subjectName
attribute of the trust anchor?
Christian
9 years, 1 month
PKI client: Utilize system-wide crypto-policies
by Christian Heimes
Hi,
this ticket in FreeIPA came to my attention:
https://fedorahosted.org/freeipa/ticket/4853
https://bugzilla.redhat.com/show_bug.cgi?id=1179220
FreeIPA isn't directly affected by the issue. But the Python client
library of Dogtag PKI uses OpenSSL and therefore indirectly affects FreeIPA.
It's also a bit related to #1253. Depending on how we want to solve
#1253 we can fix FreeIPA's #4853 at the same time. I see two solutions:
1) Use NSS for TLS/SSL. That would delay crypto-policies, because NSS
doesn't support it yet.
2) Write another SSL adapter for python-requests that allows us to use
the system certs as well as specify the cipher list.
Christian
9 years, 1 month
[PATCH] 0267-Add-code-to-reindex-data-during-cloning-without-replication
by Ade Lee
Add code to reindex data during cloning without replication
When setting up a clone, indexes are added before the
replication agreements are set up and the consumer is initialized.
Thus, as data is replicated and added to the clone db, the
data is indexed.
When cloning is done with the replication agreements already set
up and the data replicated, the existing data is not indexed and
cannot be accessed in searches. The data needs to be reindexed.
Related to ticket 1414
Please review,
Ade
9 years, 1 month
