Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-30 Thread Jan Cholasta

Dne 27.7.2012 22:50, Rob Crittenden napsal(a):

Jan Cholasta wrote:

Dne 25.7.2012 22:58, Rob Crittenden napsal(a):

Jan Cholasta wrote:


All these scripts could use more exception handling, but I guess
potential bugs can be sorted out later.


Well, they all run in the background so even if they caught errors
nothing would see them unless we decide to syslog errors.


I decided to syslog the errors, there is no other way around this.



install/share/default-aci.ldif:

The ACIs are wrong (Kerberos principal instead of ldap URI in
userdn, in
40-delegation.update it is done right).


Nice catch, not sure how I missed that. Fixed.


You forgot to fix the allow(add) one, it still has userdn =
host/$FQDN@$REALM.



Fixed.


I did:

1. ipa-server-install on host1, using IPA from master
2. ipa-replica-install on host2, using IPA from master
3. update host1 to IPA with your patch applied
4. update host2 to IPA with your patch applied
5. ipa-ca-install on host2

After that, ipaCert is not tracked on host2 at all (I had to add it
manually using getcert start-tracking -d /etc/httpd/alias -n ipaCert -c
dogtag-ipa-retrieve-agent-submit -C
/usr/lib64/ipa/certmonger/restart_httpd -p /etc/httpd/alias/pwdfile.txt
-T ipaCert).


Fixed, it wasn't being tracked on upgrades.

I filed a ticket for the audit cert renewing for only 6 months. It is a
dogtag bug.


OK, thanks.



I've seen some oddness when testing by moving the date forward, CS
replication has stopped working. I kick it with ipa-csreplica-manage
force-sync --from=master and that fixes things. This is unrelated to
my patch.

rob


ACK.

Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-30 Thread Martin Kosek
On 07/30/2012 10:54 AM, Jan Cholasta wrote:
 Dne 27.7.2012 22:50, Rob Crittenden napsal(a):
 Jan Cholasta wrote:
 Dne 25.7.2012 22:58, Rob Crittenden napsal(a):
 Jan Cholasta wrote:

 All these scripts could use more exception handling, but I guess
 potential bugs can be sorted out later.

 Well, they all run in the background so even if they caught errors
 nothing would see them unless we decide to syslog errors.

 I decided to syslog the errors, there is no other way around this.


 install/share/default-aci.ldif:

 The ACIs are wrong (Kerberos principal instead of ldap URI in
 userdn, in
 40-delegation.update it is done right).

 Nice catch, not sure how I missed that. Fixed.

 You forgot to fix the allow(add) one, it still has userdn =
 host/$FQDN@$REALM.


 Fixed.

 I did:

 1. ipa-server-install on host1, using IPA from master
 2. ipa-replica-install on host2, using IPA from master
 3. update host1 to IPA with your patch applied
 4. update host2 to IPA with your patch applied
 5. ipa-ca-install on host2

 After that, ipaCert is not tracked on host2 at all (I had to add it
 manually using getcert start-tracking -d /etc/httpd/alias -n ipaCert -c
 dogtag-ipa-retrieve-agent-submit -C
 /usr/lib64/ipa/certmonger/restart_httpd -p /etc/httpd/alias/pwdfile.txt
 -T ipaCert).

 Fixed, it wasn't being tracked on upgrades.

 I filed a ticket for the audit cert renewing for only 6 months. It is a
 dogtag bug.
 
 OK, thanks.
 

 I've seen some oddness when testing by moving the date forward, CS
 replication has stopped working. I kick it with ipa-csreplica-manage
 force-sync --from=master and that fixes things. This is unrelated to
 my patch.

 rob
 
 ACK.
 
 Honza
 

Pushed to master.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-27 Thread Rob Crittenden

Jan Cholasta wrote:

Dne 25.7.2012 22:58, Rob Crittenden napsal(a):

Jan Cholasta wrote:


All these scripts could use more exception handling, but I guess
potential bugs can be sorted out later.


Well, they all run in the background so even if they caught errors
nothing would see them unless we decide to syslog errors.


I decided to syslog the errors, there is no other way around this.



install/share/default-aci.ldif:

The ACIs are wrong (Kerberos principal instead of ldap URI in userdn, in
40-delegation.update it is done right).


Nice catch, not sure how I missed that. Fixed.


You forgot to fix the allow(add) one, it still has userdn =
host/$FQDN@$REALM.



Fixed.


I did:

1. ipa-server-install on host1, using IPA from master
2. ipa-replica-install on host2, using IPA from master
3. update host1 to IPA with your patch applied
4. update host2 to IPA with your patch applied
5. ipa-ca-install on host2

After that, ipaCert is not tracked on host2 at all (I had to add it
manually using getcert start-tracking -d /etc/httpd/alias -n ipaCert -c
dogtag-ipa-retrieve-agent-submit -C
/usr/lib64/ipa/certmonger/restart_httpd -p /etc/httpd/alias/pwdfile.txt
-T ipaCert).


Fixed, it wasn't being tracked on upgrades.

I filed a ticket for the audit cert renewing for only 6 months. It is a 
dogtag bug.


I've seen some oddness when testing by moving the date forward, CS 
replication has stopped working. I kick it with ipa-csreplica-manage 
force-sync --from=master and that fixes things. This is unrelated to 
my patch.


rob
From 040fb44ebfc5325b7b8a191ee53c9e9d29058dcc Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 11 Jul 2012 15:51:01 -0400
Subject: [PATCH] Use certmonger to renew CA subsystem certificates

Certificate renewal can be done only one one CA as the certificates need
to be shared amongst them. certmonger has been trained to communicate
directly with dogtag to perform the renewals. The initial CA installation
is the defacto certificate renewal master.

A copy of the certificate is stored in the IPA LDAP tree in
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX, the rdn being the nickname of the
certificate, when a certificate is renewed. Only the most current
certificate is stored. It is valid to have no certificates there, it means
that no renewals have taken place.

The clones are configured with a new certmonger CA type that polls this
location in the IPA tree looking for an updated certificate. If one is
not found then certmonger is put into the CA_WORKING state and will poll
every 8 hours until an updated certificate is available.

The RA agent certificate, ipaCert in /etc/httpd/alias, is a special case.
When this certificate is updated we also need to update its entry in
the dogtag tree, adding the updated certificate and telling dogtag which
certificate to use. This is the certificate that lets IPA issue
certificates.

On upgrades we check to see if the certificate tracking is already in
place. If not then we need to determine if this is the master that will
do the renewals or not. This decision is made based on whether it was
the first master installed. It is concievable that this master is no
longer available meaning that none are actually tracking renewal. We
will need to document this.

https://fedorahosted.org/freeipa/ticket/2803
---
 freeipa.spec.in|7 +-
 install/Makefile.am|1 +
 install/certmonger/Makefile.am |   14 ++
 .../certmonger/dogtag-ipa-retrieve-agent-submit|   80 +++
 install/conf/Makefile.am   |3 +-
 install/conf/ca_renewal|6 +
 install/configure.ac   |1 +
 install/restart_scripts/Makefile.am|3 +
 install/restart_scripts/renew_ca_cert  |   93 +
 install/restart_scripts/renew_ra_cert  |   96 +
 install/restart_scripts/restart_dirsrv |   25 +++-
 install/restart_scripts/restart_httpd  |   25 +++-
 install/restart_scripts/restart_pkicad |   50 +++
 install/share/bootstrap-template.ldif  |6 +
 install/share/default-aci.ldif |   10 ++
 install/tools/ipa-replica-install  |1 +
 install/tools/ipa-upgradeconfig|   52 +--
 install/updates/21-ca_renewal_container.update |8 ++
 install/updates/40-delegation.update   |4 +
 install/updates/Makefile.am|1 +
 ipalib/x509.py |8 ++
 ipapython/certmonger.py|   65 +
 ipapython/ipautil.py   |   23 +++
 ipapython/platform/base.py |2 +-
 ipapython/platform/fedora16.py |1 +
 ipaserver/install/cainstance.py|  147 

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-26 Thread Jan Cholasta

Dne 25.7.2012 22:58, Rob Crittenden napsal(a):

Jan Cholasta wrote:

Dne 25.7.2012 16:01, Rob Crittenden napsal(a):

Petr Viktorin wrote:

On 07/23/2012 10:03 PM, Rob Crittenden wrote:

Rob Crittenden wrote:

Andrew Wnuk wrote:

On 07/16/2012 01:35 PM, Rob Crittenden wrote:

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if
they
aren't?


I didn't test validating OCSP signatures but the audit subsystem
seemed fine (it complained wildly when I had the wrong trust in the
NSS db).

Andrew, do I need to update CS.cfg as well?


Yes, you may need update CS.cfg too.


Ok, added a bit to update CS.cfg with the new certificate.


This should fix some SELinux issues preventing certmonger from
monitoring the dogtag certificate database in /var/lib/pki-ca/alias.

rob


I don't know enough about dogtag/certmonger to comment on the
functionality, but there are minor issues I can find. Attaching a patch
to fix them.


`make rpms` fails:

rpmbuild --define _topdir /rpmbuild -ba freeipa.spec
error: %changelog not in descending chronological order
make: *** [rpms] Error 1



`git am` complains:

Applying: Use certmonger to renew CA subsystem certificates
/home/pviktori/freeipa/.git/rebase-apply/patch:576: new blank line at
EOF.
+
/home/pviktori/freeipa/.git/rebase-apply/patch:645: new blank line at
EOF.
+
warning: 2 lines add whitespace errors.


Thanks, integrated this patch and added a missing script, renew_ipacert.

rob



NACK


First, a question: I haven't tested this (yet), but what happens when
someone uses the --{dirsrv,http,pkinit}_pkcs12 options of
ipa-server-install/ipa-replica-prepare? (There are also other options
which I suspect may cause trouble, namely --subject and --selfsign.)


CA certs aren't tracked if --selfsign is used.

subject doesn't matter, it is unrelated to renewal.

The provided PKCS#12 files are unrelated to this patch, but in general
we will still attempt to renew the dirsrv and http certs. We
automatically track all certs using the IPA CA. If they were not issued
by the IPA CA then they will fail to be renewed.


OK, thanks.



I'm thinking we need to deprecate ipa-server-certs and document that
using the PKCS#12 options is unsupported.



install/restart_scripts/renew_ra_cert doesn't seem to be used anywhere.


This replaces the ipaCert script. I fixed up the invocation.


ipa-replica-install --setup-ca fails with:

...
   [13/15]: configure clone certificate renewals

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Nickname ipaCert doesn't exist in NSS database /etc/httpd/alias


Fixed.


On clones, the CN=IPA RA,O=REALM certificate is tracked with post-save
command '/usr/lib64/ipa/certmonger/restart_httpd ipaCert', but
restart_httpd does not take any arguments (it does not break anything,
it's just weird).


That's true, suppressed.



Comments on individual files follow:


install/certmonger/Makefile.am:

Missing closing parenthesis:

+EXTRA_DIST =\
+$(app_SCRIPTS   \


Fixed, and replaced some spaces with tabs.



install/certmonger/dogtag-ipa-retrieve-agent-submit:

Typo (nicknamd):


Fixed.


Are these guaranteed to be upper-case? I'd put operation.upper() here,
just to be on the safe side:


Yes, guaranteed to be upper-case from certmonger.


This except block is not necessary, unhandled exceptions are caught in
the except block lower in the code:

+sys.exit(5)
+except Exception, e:
+# Unhandled error
+sys.exit(3)
+finally:


Sure, removed. I had it there for readability but it is such little code
it can still be followed.




install/restart_scripts/restart_dirsrv:

You import and initialize api, but then don't use it.


Ah, I did at one point, then ripped it all out (or almost all,
apparently). Gone.



install/restart_scripts/*:

All these scripts could use more exception handling, but I guess
potential bugs can be sorted out later.


Well, they all run in the background so even if they caught errors
nothing would see them unless we decide to syslog errors.



install/share/default-aci.ldif:

The ACIs are wrong (Kerberos principal instead of ldap URI in userdn, in
40-delegation.update it is done right).


Nice catch, not sure how I missed that. Fixed.


You forgot to fix the allow(add) one, it still has userdn = 
host/$FQDN@$REALM.






ipapython/certmonger.py:

This is ugly:

+if sys.maxsize  2**32:
+libpath = 'lib64'
+else:
+libpath = 'lib'


I'm open to suggestions, it's the best thing I could find.


OK, it is mentioned in http://docs.python.org/library/platform.html, 
so it is probably safe.


However, I think that in future it 

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-25 Thread Rob Crittenden

Petr Viktorin wrote:

On 07/23/2012 10:03 PM, Rob Crittenden wrote:

Rob Crittenden wrote:

Andrew Wnuk wrote:

On 07/16/2012 01:35 PM, Rob Crittenden wrote:

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?


I didn't test validating OCSP signatures but the audit subsystem
seemed fine (it complained wildly when I had the wrong trust in the
NSS db).

Andrew, do I need to update CS.cfg as well?


Yes, you may need update CS.cfg too.


Ok, added a bit to update CS.cfg with the new certificate.


This should fix some SELinux issues preventing certmonger from
monitoring the dogtag certificate database in /var/lib/pki-ca/alias.

rob


I don't know enough about dogtag/certmonger to comment on the
functionality, but there are minor issues I can find. Attaching a patch
to fix them.


`make rpms` fails:

rpmbuild --define _topdir /rpmbuild -ba freeipa.spec
error: %changelog not in descending chronological order
make: *** [rpms] Error 1



`git am` complains:

Applying: Use certmonger to renew CA subsystem certificates
/home/pviktori/freeipa/.git/rebase-apply/patch:576: new blank line at EOF.
+
/home/pviktori/freeipa/.git/rebase-apply/patch:645: new blank line at EOF.
+
warning: 2 lines add whitespace errors.


Thanks, integrated this patch and added a missing script, renew_ipacert.

rob


From 5f056eb1a88f1af92b2fe950bd3e6fa53502a3df Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 11 Jul 2012 15:51:01 -0400
Subject: [PATCH] Use certmonger to renew CA subsystem certificates

Certificate renewal can be done only one one CA as the certificates need
to be shared amongst them. certmonger has been trained to communicate
directly with dogtag to perform the renewals. The initial CA installation
is the defacto certificate renewal master.

A copy of the certificate is stored in the IPA LDAP tree in
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX, the rdn being the nickname of the
certificate, when a certificate is renewed. Only the most current
certificate is stored. It is valid to have no certificates there, it means
that no renewals have taken place.

The clones are configured with a new certmonger CA type that polls this
location in the IPA tree looking for an updated certificate. If one is
not found then certmonger is put into the CA_WORKING state and will poll
every 8 hours until an updated certificate is available.

The RA agent certificate, ipaCert in /etc/httpd/alias, is a special case.
When this certificate is updated we also need to update its entry in
the dogtag tree, adding the updated certificate and telling dogtag which
certificate to use. This is the certificate that lets IPA issue
certificates.

On upgrades we check to see if the certificate tracking is already in
place. If not then we need to determine if this is the master that will
do the renewals or not. This decision is made based on whether it was
the first master installed. It is concievable that this master is no
longer available meaning that none are actually tracking renewal. We
will need to document this.

https://fedorahosted.org/freeipa/ticket/2803
---
 freeipa.spec.in|7 +-
 install/Makefile.am|1 +
 install/certmonger/Makefile.am |   14 +++
 .../certmonger/dogtag-ipa-retrieve-agent-submit|   79 +
 install/conf/Makefile.am   |3 +-
 install/conf/ca_renewal|6 +
 install/configure.ac   |1 +
 install/restart_scripts/Makefile.am|4 +
 install/restart_scripts/renew_ca_cert  |   81 +
 install/restart_scripts/renew_ipacert  |   56 +
 install/restart_scripts/renew_ra_cert  |   82 +
 install/restart_scripts/restart_dirsrv |   24 
 install/restart_scripts/restart_httpd  |   20 
 install/restart_scripts/restart_pkicad |   44 +++
 install/share/bootstrap-template.ldif  |6 +
 install/share/default-aci.ldif |   10 ++
 install/tools/ipa-upgradeconfig|   29 +
 install/updates/21-ca_renewal_container.update |8 ++
 install/updates/40-delegation.update   |4 +
 install/updates/Makefile.am|1 +
 ipalib/x509.py |8 ++
 ipapython/certmonger.py|   68 +++
 ipapython/ipautil.py   |   23 
 ipapython/platform/base.py |2 +-
 ipapython/platform/fedora16.py |1 +
 

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-25 Thread Jan Cholasta

Dne 25.7.2012 16:01, Rob Crittenden napsal(a):

Petr Viktorin wrote:

On 07/23/2012 10:03 PM, Rob Crittenden wrote:

Rob Crittenden wrote:

Andrew Wnuk wrote:

On 07/16/2012 01:35 PM, Rob Crittenden wrote:

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?


I didn't test validating OCSP signatures but the audit subsystem
seemed fine (it complained wildly when I had the wrong trust in the
NSS db).

Andrew, do I need to update CS.cfg as well?


Yes, you may need update CS.cfg too.


Ok, added a bit to update CS.cfg with the new certificate.


This should fix some SELinux issues preventing certmonger from
monitoring the dogtag certificate database in /var/lib/pki-ca/alias.

rob


I don't know enough about dogtag/certmonger to comment on the
functionality, but there are minor issues I can find. Attaching a patch
to fix them.


`make rpms` fails:

rpmbuild --define _topdir /rpmbuild -ba freeipa.spec
error: %changelog not in descending chronological order
make: *** [rpms] Error 1



`git am` complains:

Applying: Use certmonger to renew CA subsystem certificates
/home/pviktori/freeipa/.git/rebase-apply/patch:576: new blank line at
EOF.
+
/home/pviktori/freeipa/.git/rebase-apply/patch:645: new blank line at
EOF.
+
warning: 2 lines add whitespace errors.


Thanks, integrated this patch and added a missing script, renew_ipacert.

rob



NACK


First, a question: I haven't tested this (yet), but what happens when 
someone uses the --{dirsrv,http,pkinit}_pkcs12 options of 
ipa-server-install/ipa-replica-prepare? (There are also other options 
which I suspect may cause trouble, namely --subject and --selfsign.)



install/restart_scripts/renew_ra_cert doesn't seem to be used anywhere.


ipa-replica-install --setup-ca fails with:

...
  [13/15]: configure clone certificate renewals

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Nickname ipaCert doesn't exist in NSS database /etc/httpd/alias

ipareplica-install.log:

...
2012-07-25T11:49:17Z DEBUG args=/usr/bin/certutil -L -d /etc/httpd/alias 
-n ipaCert

2012-07-25T11:49:17Z DEBUG stdout=
2012-07-25T11:49:17Z DEBUG stderr=certutil: Could not find cert: ipaCert
: File not found

2012-07-25T11:49:17Z INFO   File 
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, 
line 604, in run_script

return_value = main_function()

  File /sbin/ipa-replica-install, line 446, in main
(CA, cs) = cainstance.install_replica_ca(config)

  File 
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 
1265, in install_replica_ca

subject_base=config.subject_base)

  File 
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 
554, in configure_instance

self.start_creation(Configuring certificate server, 210)

  File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, 
line 261, in start_creation

method()

  File 
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 
1158, in configure_clone_renewal


certmonger.dogtag_start_tracking('dogtag-ipa-retrieve-agent-submit', 
'ipaCert', None, '/etc/httpd/alias/pwdfile.txt', '/etc/httpd/alias', 
'restart_httpd')


  File /usr/lib/python2.7/site-packages/ipapython/certmonger.py, line 
364, in dogtag_start_tracking
raise RuntimeError('Nickname %s doesn\'t exist in NSS database 
%s' % (nickname, secdir))


2012-07-25T11:49:17Z INFO The ipa-replica-install command failed, 
exception: RuntimeError: Nickname ipaCert doesn't exist in NSS 
database /etc/httpd/alias



(ipa-ca-install doesn't seem to suffer from the above issue.)


On clones, the CN=IPA RA,O=REALM certificate is tracked with post-save 
command '/usr/lib64/ipa/certmonger/restart_httpd ipaCert', but 
restart_httpd does not take any arguments (it does not break anything, 
it's just weird).



Comments on individual files follow:


install/certmonger/Makefile.am:

Missing closing parenthesis:

+EXTRA_DIST =\
+$(app_SCRIPTS   \


install/certmonger/dogtag-ipa-retrieve-agent-submit:

Typo (nicknamd):

+# We cheat and pass in the nicknamd as the CA profile to execute against.

Are these guaranteed to be upper-case? I'd put operation.upper() here, 
just to be on the safe side:


+if operation not in ['SUBMIT', 'POLL']:
+sys.exit(6) # unsupported operation

This except block is not necessary, unhandled exceptions are caught in 
the except block lower in the code:


+sys.exit(5)
+except Exception, e:
+# Unhandled error
+sys.exit(3)
+finally:


install/restart_scripts/restart_dirsrv:

You import and initialize api, but then don't use it.


install/restart_scripts/*:

All 

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-24 Thread Petr Viktorin

On 07/23/2012 10:03 PM, Rob Crittenden wrote:

Rob Crittenden wrote:

Andrew Wnuk wrote:

On 07/16/2012 01:35 PM, Rob Crittenden wrote:

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?


I didn't test validating OCSP signatures but the audit subsystem
seemed fine (it complained wildly when I had the wrong trust in the
NSS db).

Andrew, do I need to update CS.cfg as well?


Yes, you may need update CS.cfg too.


Ok, added a bit to update CS.cfg with the new certificate.


This should fix some SELinux issues preventing certmonger from
monitoring the dogtag certificate database in /var/lib/pki-ca/alias.

rob


I don't know enough about dogtag/certmonger to comment on the 
functionality, but there are minor issues I can find. Attaching a patch 
to fix them.



`make rpms` fails:

rpmbuild --define _topdir /rpmbuild -ba freeipa.spec
error: %changelog not in descending chronological order
make: *** [rpms] Error 1



`git am` complains:

Applying: Use certmonger to renew CA subsystem certificates
/home/pviktori/freeipa/.git/rebase-apply/patch:576: new blank line at EOF.
+
/home/pviktori/freeipa/.git/rebase-apply/patch:645: new blank line at EOF.
+
warning: 2 lines add whitespace errors.


--
PetrĀ³
From 047a1f7dc78c632b7f9882ab21f1fe5dc82fb006 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 24 Jul 2012 04:43:28 -0400
Subject: [PATCH] fixes for rcrit-1033-03

---
 freeipa.spec.in|2 +-
 install/share/default-aci.ldif |1 -
 install/updates/21-ca_renewal_container.update |1 -
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index ce6c21aa3d9a6d92f6125e36905df5d3cf7b1a74..002a70a4385a502edc0c99b9b56ebbe02ef392ad 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -745,7 +745,7 @@ fi
 %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt
 
 %changelog
-* Fri Jul  6 2012 Rob Crittenden rcrit...@redhat.com - 2.99.0-39
+* Tue Jul 24 2012 Rob Crittenden rcrit...@redhat.com - 2.99.0-39
 - Set minimum certmonger to 0.58 for dogtag cert renewal
 
 * Wed Jul 18 2012 Alexander Bokovoy aboko...@redhat.com - 2.99.0-38
diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif
index 2fc04f667d3abe3a831c7d116c130c903f8e5106..6199ae5a68f648ca4e9fa6ded8083e5dcc07cb78 100644
--- a/install/share/default-aci.ldif
+++ b/install/share/default-aci.ldif
@@ -96,4 +96,3 @@ dn: cn=ipa,cn=etc,$SUFFIX
 changetype: modify
 add: aci
 aci: (target=ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX;)(targetattr=userCertificate)(version 3.0; acl Modify CA Certificates for renewals; allow(write) userdn = host/$FQDN@$REALM;)
-
diff --git a/install/updates/21-ca_renewal_container.update b/install/updates/21-ca_renewal_container.update
index edb8f3e37bf8f6dee191782b8b2519f198fb3cd1..50b92d73d8af75cbc782769c45b6c439b07bbb2d 100644
--- a/install/updates/21-ca_renewal_container.update
+++ b/install/updates/21-ca_renewal_container.update
@@ -6,4 +6,3 @@ dn: cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX
 add:objectClass: top
 add:objectClass: nsContainer
 add:cn: ca_renewal
-
-- 
1.7.10.4

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-23 Thread Rob Crittenden

Rob Crittenden wrote:

Andrew Wnuk wrote:

On 07/16/2012 01:35 PM, Rob Crittenden wrote:

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?


I didn't test validating OCSP signatures but the audit subsystem
seemed fine (it complained wildly when I had the wrong trust in the
NSS db).

Andrew, do I need to update CS.cfg as well?


Yes, you may need update CS.cfg too.


Ok, added a bit to update CS.cfg with the new certificate.


This should fix some SELinux issues preventing certmonger from 
monitoring the dogtag certificate database in /var/lib/pki-ca/alias.


rob
From e2e7ed28946cabd47dfdb74b071125a3ec123446 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 11 Jul 2012 15:51:01 -0400
Subject: [PATCH] Use certmonger to renew CA subsystem certificates

Certificate renewal can be done only one one CA as the certificates need
to be shared amongst them. certmonger has been trained to communicate
directly with dogtag to perform the renewals. The initial CA installation
is the defacto certificate renewal master.

A copy of the certificate is stored in the IPA LDAP tree in
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX, the rdn being the nickname of the
certificate, when a certificate is renewed. Only the most current
certificate is stored. It is valid to have no certificates there, it means
that no renewals have taken place.

The clones are configured with a new certmonger CA type that polls this
location in the IPA tree looking for an updated certificate. If one is
not found then certmonger is put into the CA_WORKING state and will poll
every 8 hours until an updated certificate is available.

The RA agent certificate, ipaCert in /etc/httpd/alias, is a special case.
When this certificate is updated we also need to update its entry in
the dogtag tree, adding the updated certificate and telling dogtag which
certificate to use. This is the certificate that lets IPA issue
certificates.

On upgrades we check to see if the certificate tracking is already in
place. If not then we need to determine if this is the master that will
do the renewals or not. This decision is made based on whether it was
the first master installed. It is concievable that this master is no
longer available meaning that none are actually tracking renewal. We
will need to document this.

https://fedorahosted.org/freeipa/ticket/2803
---
 freeipa.spec.in|7 +-
 install/Makefile.am|1 +
 install/certmonger/Makefile.am |   14 +++
 .../certmonger/dogtag-ipa-retrieve-agent-submit|   79 +
 install/conf/Makefile.am   |3 +-
 install/conf/ca_renewal|6 +
 install/configure.ac   |1 +
 install/restart_scripts/Makefile.am|3 +
 install/restart_scripts/renew_ca_cert  |   81 +
 install/restart_scripts/renew_ra_cert  |   82 +
 install/restart_scripts/restart_dirsrv |   24 
 install/restart_scripts/restart_httpd  |   20 
 install/restart_scripts/restart_pkicad |   44 +++
 install/share/bootstrap-template.ldif  |6 +
 install/share/default-aci.ldif |   11 ++
 install/tools/ipa-upgradeconfig|   29 +
 install/updates/21-ca_renewal_container.update |9 ++
 install/updates/40-delegation.update   |4 +
 install/updates/Makefile.am|1 +
 ipalib/x509.py |8 ++
 ipapython/certmonger.py|   68 +++
 ipapython/ipautil.py   |   23 
 ipapython/platform/base.py |2 +-
 ipapython/platform/fedora16.py |1 +
 ipaserver/install/cainstance.py|  125 +++-
 selinux/ipa_dogtag/ipa_dogtag.te   |   10 +-
 26 files changed, 656 insertions(+), 6 deletions(-)
 create mode 100644 install/certmonger/Makefile.am
 create mode 100644 install/certmonger/dogtag-ipa-retrieve-agent-submit
 create mode 100644 install/conf/ca_renewal
 create mode 100644 install/restart_scripts/renew_ca_cert
 create mode 100644 install/restart_scripts/renew_ra_cert
 create mode 100644 install/restart_scripts/restart_pkicad
 create mode 100644 install/updates/21-ca_renewal_container.update

diff --git a/freeipa.spec.in b/freeipa.spec.in
index f4903c01354764f0c6b8755824512edbc1ff930b..ce6c21aa3d9a6d92f6125e36905df5d3cf7b1a74 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -247,7 +247,7 @@ 

[Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-16 Thread Rob Crittenden
Use the new certmonger capability to be able to renew the dogtag 
subsystem certificates (audit, OCSP, etc).


See the ticket for full details.

rob
From a8932452a1a7343ffe0263183ef63e1efe6a7a6b Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 11 Jul 2012 15:51:01 -0400
Subject: [PATCH] Use certmonger to renew CA subsystem certificates

Certificate renewal can be done only one one CA as the certificates need
to be shared amongst them. certmonger has been trained to communicate
directly with dogtag to perform the renewals. The initial CA installation
is the defacto certificate renewal master.

A copy of the certificate is stored in the IPA LDAP tree in
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX, the rdn being the nickname of the
certificate, when a certificate is renewed. Only the most current
certificate is stored. It is valid to have no certificates there, it means
that no renewals have taken place.

The clones are configured with a new certmonger CA type that polls this
location in the IPA tree looking for an updated certificate. If one is
not found then certmonger is put into the CA_WORKING state and will poll
every 8 hours until an updated certificate is available.

The RA agent certificate, ipaCert in /etc/httpd/alias, is a special case.
When this certificate is updated we also need to update its entry in
the dogtag tree, adding the updated certificate and telling dogtag which
certificate to use. This is the certificate that lets IPA issue
certificates.

On upgrades we check to see if the certificate tracking is already in
place. If not then we need to determine if this is the master that will
do the renewals or not. This decision is made based on whether it was
the first master installed. It is concievable that this master is no
longer available meaning that none are actually tracking renewal. We
will need to document this.

https://fedorahosted.org/freeipa/ticket/2803
---
 freeipa.spec.in|7 +-
 install/Makefile.am|1 +
 install/certmonger/Makefile.am |   14 +++
 .../certmonger/dogtag-ipa-retrieve-agent-submit|   79 +++
 install/conf/Makefile.am   |3 +-
 install/conf/ca_renewal|6 ++
 install/configure.ac   |1 +
 install/restart_scripts/Makefile.am|3 +
 install/restart_scripts/renew_ca_cert  |   78 ++
 install/restart_scripts/renew_ra_cert  |   82 +++
 install/restart_scripts/restart_dirsrv |   24 +
 install/restart_scripts/restart_httpd  |   20 
 install/restart_scripts/restart_pkicad |   44 
 install/share/bootstrap-template.ldif  |6 ++
 install/share/default-aci.ldif |   11 ++
 install/tools/ipa-upgradeconfig|   29 ++
 install/updates/21-ca_renewal_container.update |9 ++
 install/updates/40-delegation.update   |4 +
 install/updates/Makefile.am|1 +
 ipalib/x509.py |8 ++
 ipapython/certmonger.py|   67 +
 ipapython/ipautil.py   |   23 +
 ipapython/platform/base.py |2 +-
 ipapython/platform/fedora16.py |1 +
 ipaserver/install/cainstance.py|  106 +++-
 25 files changed, 624 insertions(+), 5 deletions(-)
 create mode 100644 install/certmonger/Makefile.am
 create mode 100644 install/certmonger/dogtag-ipa-retrieve-agent-submit
 create mode 100644 install/conf/ca_renewal
 create mode 100644 install/restart_scripts/renew_ca_cert
 create mode 100644 install/restart_scripts/renew_ra_cert
 create mode 100644 install/restart_scripts/restart_pkicad
 create mode 100644 install/updates/21-ca_renewal_container.update

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 7106310915c8a4e52a009036f7152a38a4c5f18d..be24bfcb609773636d537f94d721d3839baed823 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -247,7 +247,7 @@ Requires:  xmlrpc-c
 %endif
 %endif
 Requires: sssd = 1.8.0
-Requires: certmonger = 0.53
+Requires: certmonger = 0.58
 Requires: nss-tools
 Requires: bind-utils
 Requires: oddjob-mkhomedir
@@ -569,6 +569,7 @@ fi
 %{_sbindir}/ipactl
 %{_sbindir}/ipa-upgradeconfig
 %{_sbindir}/ipa-compliance
+%{_libexecdir}/certmonger/dogtag-ipa-retrieve-agent-submit
 %{_sysconfdir}/cron.d/ipa-compliance
 %config(noreplace) %{_sysconfdir}/sysconfig/ipa_memcached
 %dir %attr(0700,apache,apache) %{_localstatedir}/run/ipa_memcached/
@@ -631,6 +632,7 @@ fi
 %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/httpd/conf.d/ipa-rewrite.conf
 %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/httpd/conf.d/ipa.conf
 %ghost %attr(0644,root,apache) 

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-16 Thread Nalin Dahyabhai
On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:
 Use the new certmonger capability to be able to renew the dogtag
 subsystem certificates (audit, OCSP, etc).

Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?

Nalin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-16 Thread Rob Crittenden

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?


I didn't test validating OCSP signatures but the audit subsystem seemed 
fine (it complained wildly when I had the wrong trust in the NSS db).


Andrew, do I need to update CS.cfg as well?

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

2012-07-16 Thread Andrew Wnuk

On 07/16/2012 01:35 PM, Rob Crittenden wrote:

Nalin Dahyabhai wrote:

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:

Use the new certmonger capability to be able to renew the dogtag
subsystem certificates (audit, OCSP, etc).


Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?


I didn't test validating OCSP signatures but the audit subsystem 
seemed fine (it complained wildly when I had the wrong trust in the 
NSS db).


Andrew, do I need to update CS.cfg as well?


Yes, you may need update CS.cfg too.

Andrew

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel