Re: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal
On 17.6.2016 09:34, Fraser Tweedale wrote: On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote: Hi, On 6.5.2016 08:01, Fraser Tweedale wrote: Hullo all, FreeIPA Lightweight CAs implementation is progressing well. The remaining big unknown in the design is how to do renewal. I have put my ideas into the design page[1] and would appreciate any and all feedback! [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal Some brief commentary on the options: I intend to implement approach (1) as a baseline. Apart from implementing machinery in Dogtag to actually perform the renewal - which is required for all the approaches - it's not much work and gets us over the "lightweight CAs can be renewed easily" line, even if it is a manual process. For automatic renewal, I am leaning towards approach (2). Dogtag owns the lightweight CAs so I think it makes sense to give Dogtag the ability to renew them automatically (if configured to do so), without relying on external tools i.e. Certmonger. But as you will see from the outlines, each approach has its upside and downside. I would prefer (3), as I would very much like to avoid duplicating certmonger's functionality in Dogtag. Some comments on the disadvantages: * "Proliferation of Certmonger tracking requests; one for each FreeIPA-managed lightweight CA." I don't think this is an actual issue, as it's purely cosmetic. * "Either lightweight CA creation is restricted to the renewal master, or the renewal master must observe the creation of new lightweight CAs and start tracking their certificate." IMO this doesn't have to be done automatically in the initial implementation. You could extend ipa-certupdate to set up certmonger for lightweight CAs and have admins run it manually on masters after adding a new lightweight CA. They will have to run it anyway to get the new lightweight CA certificate installed in the system, so it should be fine to do it this way. I have updated the renew_ca_cert post-save script to perform the database update necessary for CA replicas to pick up the new cert. What remains is the command to tell certmonger to track the CA. You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a better fit, e.g.: ipa-cacert-manage track It would look up the necessary info (basically just the CA-ID) and set up the certmonger tracking. No. ipa-cacert-manage updates global configuration in LDAP, whereas ipa-certupdate applies the global configuration on the local system. Updating certmonger configuration is the latter, hence it should be done in ipa-certupdate. Also, I don't think we should expose (un)tracking certificates by CA ID to users, as all our CA certificates should always be tracked. It could be an error to run the command on other than the renewal master. Note that the main CA certificate is tracked on all CA servers, not just the renewal master, otherwise it wouldn't get updated on the other CA servers after renewal. I would think the same needs to be done for lightweight CA certificates, unless there is a different mechanism for distributing the certificates to other CA masters, in which case I would prefer if the mechanism was also used for the main CA certificate. An untrack command could also be provided. Thoughts? * "Development of new Certmonger renewal helpers solely for lightweight CA renewal." It would be easier to extend the existing helpers. I don't think there is anything preventing them from being used for lighweight CAs, except not conveying the CA name, which should be easy to implement. I would also avoid starting with (1), I don't believe it adds any real value. IMHO the first thing that should be done is implement lightweight CA support in certmonger (add new 'request' / 'start-tracking' option for CA name, store it in tracking requests, pass it to CA helpers in a new environment variable). Honza -- Jan Cholasta -- Jan Cholasta ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal
On 18.6.2016 02:38, Fraser Tweedale wrote: On Fri, Jun 17, 2016 at 03:21:07PM +0200, Jan Cholasta wrote: On 17.6.2016 09:34, Fraser Tweedale wrote: On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote: Hi, On 6.5.2016 08:01, Fraser Tweedale wrote: Hullo all, FreeIPA Lightweight CAs implementation is progressing well. The remaining big unknown in the design is how to do renewal. I have put my ideas into the design page[1] and would appreciate any and all feedback! [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal Some brief commentary on the options: I intend to implement approach (1) as a baseline. Apart from implementing machinery in Dogtag to actually perform the renewal - which is required for all the approaches - it's not much work and gets us over the "lightweight CAs can be renewed easily" line, even if it is a manual process. For automatic renewal, I am leaning towards approach (2). Dogtag owns the lightweight CAs so I think it makes sense to give Dogtag the ability to renew them automatically (if configured to do so), without relying on external tools i.e. Certmonger. But as you will see from the outlines, each approach has its upside and downside. I would prefer (3), as I would very much like to avoid duplicating certmonger's functionality in Dogtag. Some comments on the disadvantages: * "Proliferation of Certmonger tracking requests; one for each FreeIPA-managed lightweight CA." I don't think this is an actual issue, as it's purely cosmetic. * "Either lightweight CA creation is restricted to the renewal master, or the renewal master must observe the creation of new lightweight CAs and start tracking their certificate." IMO this doesn't have to be done automatically in the initial implementation. You could extend ipa-certupdate to set up certmonger for lightweight CAs and have admins run it manually on masters after adding a new lightweight CA. They will have to run it anyway to get the new lightweight CA certificate installed in the system, so it should be fine to do it this way. I have updated the renew_ca_cert post-save script to perform the database update necessary for CA replicas to pick up the new cert. What remains is the command to tell certmonger to track the CA. You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a better fit, e.g.: ipa-cacert-manage track It would look up the necessary info (basically just the CA-ID) and set up the certmonger tracking. No. ipa-cacert-manage updates global configuration in LDAP, whereas ipa-certupdate applies the global configuration on the local system. Updating certmonger configuration is the latter, hence it should be done in ipa-certupdate. Also, I don't think we should expose (un)tracking certificates by CA ID to users, as all our CA certificates should always be tracked. OK, so ipa-certupdate just gets run without arguments on a CA master, and it ensures that all CA certificates are tracked by Certmonger. Right. Makes sense to me. Thanks for the clarifications. It could be an error to run the command on other than the renewal master. Note that the main CA certificate is tracked on all CA servers, not just the renewal master, otherwise it wouldn't get updated on the other CA servers after renewal. I would think the same needs to be done for lightweight CA certificates, unless there is a different mechanism for distributing the certificates to other CA masters, in which case I would prefer if the mechanism was also used for the main CA certificate. There is a different mechanism that causes other CA masters to update their NSSDBs with the new certificate. After the renewal is performed, the authoritySerial attribute is updated in the authority's entry in Dogtag's database; other CA replicas replicas notice the update and install the new cert in their own NSSDBs without requiring restart (thus, we only need to track LWCA certs on the renewal master). The mechanism is available on versions of Dogtag that support lightweight CAs, with the ou=authorities container existing in Dogtag's database. It should work for the main CA, but I have not tested this yet. Sounds great! I hope it works, I would very much like to get rid of our thing now that Dogtag handles it. An untrack command could also be provided. Thoughts? * "Development of new Certmonger renewal helpers solely for lightweight CA renewal." It would be easier to extend the existing helpers. I don't think there is anything preventing them from being used for lighweight CAs, except not conveying the CA name, which should be easy to implement. I would also avoid starting with (1), I don't believe it adds any real value. IMHO the first thing that should be done is implement lightweight CA support in certmonger (add new 'request' / 'start-tracking' option for CA name, store it in tracking requests, pass it to CA helpers in a new environment variable). Honza -- Jan Cholasta -- Jan Cholasta
Re: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal
On 9.5.2016 18:27, Petr Vobornik wrote: On 05/09/2016 09:35 AM, Jan Cholasta wrote: Hi, On 6.5.2016 08:01, Fraser Tweedale wrote: Hullo all, FreeIPA Lightweight CAs implementation is progressing well. The remaining big unknown in the design is how to do renewal. I have put my ideas into the design page[1] and would appreciate any and all feedback! [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal Some brief commentary on the options: I intend to implement approach (1) as a baseline. Apart from implementing machinery in Dogtag to actually perform the renewal - which is required for all the approaches - it's not much work and gets us over the "lightweight CAs can be renewed easily" line, even if it is a manual process. For automatic renewal, I am leaning towards approach (2). Dogtag owns the lightweight CAs so I think it makes sense to give Dogtag the ability to renew them automatically (if configured to do so), without relying on external tools i.e. Certmonger. But as you will see from the outlines, each approach has its upside and downside. I would prefer (3), as I would very much like to avoid duplicating certmonger's functionality in Dogtag. Some comments on the disadvantages: * "Proliferation of Certmonger tracking requests; one for each FreeIPA-managed lightweight CA." I don't think this is an actual issue, as it's purely cosmetic. * "Either lightweight CA creation is restricted to the renewal master, or the renewal master must observe the creation of new lightweight CAs and start tracking their certificate." IMO this doesn't have to be done automatically in the initial implementation. You could extend ipa-certupdate to set up certmonger for lightweight CAs and have admins run it manually on masters after adding a new lightweight CA. They will have to run it anyway to get the new lightweight CA certificate installed in the system, so it should be fine to do it this way. I'm afraid that it can lead to errors where admins would distribute the cert by other means and as a result this command would not be run on renewal master even though it is easier. But it is still better than #1 without auto-renewal mechanism. Admins can screw up using any of the proposed approaches, so IMHO this argument is invalid :-) * "Development of new Certmonger renewal helpers solely for lightweight CA renewal." It would be easier to extend the existing helpers. I don't think there is anything preventing them from being used for lighweight CAs, except not conveying the CA name, which should be easy to implement. I would also avoid starting with (1), I don't believe it adds any real value. IMHO the first thing that should be done is implement lightweight CA support in certmonger (add new 'request' / 'start-tracking' option for CA name, store it in tracking requests, pass it to CA helpers in a new environment variable). Honza -- Jan Cholasta ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] rpm version issues in ogtag-pki-theme
Hi Matt Note you'll have problems here, a beta should have a version like 10.3.0-0.b1 not 10.3.0.b1-1 because it won't upgrade properly because 10.3.0.b1 > 10.3.0 in versions. Details can be found in the packaging guidelines: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages Peter = DOWNGRADED PACKAGES = Package: dogtag-pki-theme-10.3.0-1.fc25 Old package: dogtag-pki-theme-10.3.0.b1-1.fc25 Summary: Certificate System - PKI Console User Interface RPMs: dogtag-pki-console-theme dogtag-pki-server-theme Size: 405976 bytes Size change: -304 bytes Changelog: * Mon May 16 2016 Dogtag Team 10.3.0-1 - Updated version number to 10.3.0-1 ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal
Hi, On 6.5.2016 08:01, Fraser Tweedale wrote: Hullo all, FreeIPA Lightweight CAs implementation is progressing well. The remaining big unknown in the design is how to do renewal. I have put my ideas into the design page[1] and would appreciate any and all feedback! [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal Some brief commentary on the options: I intend to implement approach (1) as a baseline. Apart from implementing machinery in Dogtag to actually perform the renewal - which is required for all the approaches - it's not much work and gets us over the "lightweight CAs can be renewed easily" line, even if it is a manual process. For automatic renewal, I am leaning towards approach (2). Dogtag owns the lightweight CAs so I think it makes sense to give Dogtag the ability to renew them automatically (if configured to do so), without relying on external tools i.e. Certmonger. But as you will see from the outlines, each approach has its upside and downside. I would prefer (3), as I would very much like to avoid duplicating certmonger's functionality in Dogtag. Some comments on the disadvantages: * "Proliferation of Certmonger tracking requests; one for each FreeIPA-managed lightweight CA." I don't think this is an actual issue, as it's purely cosmetic. * "Either lightweight CA creation is restricted to the renewal master, or the renewal master must observe the creation of new lightweight CAs and start tracking their certificate." IMO this doesn't have to be done automatically in the initial implementation. You could extend ipa-certupdate to set up certmonger for lightweight CAs and have admins run it manually on masters after adding a new lightweight CA. They will have to run it anyway to get the new lightweight CA certificate installed in the system, so it should be fine to do it this way. * "Development of new Certmonger renewal helpers solely for lightweight CA renewal." It would be easier to extend the existing helpers. I don't think there is anything preventing them from being used for lighweight CAs, except not conveying the CA name, which should be easy to implement. I would also avoid starting with (1), I don't believe it adds any real value. IMHO the first thing that should be done is implement lightweight CA support in certmonger (add new 'request' / 'start-tracking' option for CA name, store it in tracking requests, pass it to CA helpers in a new environment variable). Honza -- Jan Cholasta ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [pki-devel][PATCH] 0073-Separated-TPS-does-not-automatically-receive-shared-.patch
[PATCH] Separated TPS does not automatically receive shared secret from remote TKS. Support to allow the TPS to do the following: 1. Request that the TKS creates a shared secret with the proper ID, pointing to the TPS. 2. Have the TKS securely return the shared secret back to the TPS during the end of configuration. 3. The TPS then imports the wrapped shared secret into it's own internal NSS db permanenty and. 4. Given a name that is mapped to the TPS's id string. Additional fixes: 1. The TKS was modified to actually be able to use multiple shared secrets registered by multiple TPS instances. Caveat: At this point if the same remote TPS instance is created over and over again, the TPS's user in the TKS will accumulate "userCert" attributes, making the exportation of teh shared secret not functional. At this point we need to assume that the TPS user has ONE "userCert" registered at this time. Tested with a remote TPS talking to a shared TMS system consisting of a TPS, TKS, and KRA . The shared secret was imported successfully after manually deleting the user representing the TPS from previous installs. This way I was assured one cert stored for the user, since it had to be created fresh. Also tested that the TKS can work successfully with the new TPS AND the prior shared TPS on the original instance. The TKS can now host more than one shared secret in it's db and address the correct one when a given TPS makes a request of it. Please forgive some spurious changes that happened when formatting a couple of the files in question. Every legit change is related to the shared secret and can be found easily.From ef5d954d1160002f6ed0ff05894f5968d7982d24 Mon Sep 17 00:00:00 2001 From: Jack Magne Date: Mon, 13 Jun 2016 11:27:59 -0700 Subject: [PATCH] Separated TPS does not automatically receive shared secret from remote TKS. Support to allow the TPS to do the following: 1. Request that the TKS creates a shared secret with the proper ID, pointing to the TPS. 2. Have the TKS securely return the shared secret back to the TPS during the end of configuration. 3. The TPS then imports the wrapped shared secret into it's own internal NSS db permanenty and. 4. Given a name that is mapped to the TPS's id string. Additional fixes: 1. The TKS was modified to actually be able to use multiple shared secrets registered by multiple TPS instances. Caveat: At this point if the same remote TPS instance is created over and over again, the TPS's user in the TKS will accumulate "userCert" attributes, making the exportation of teh shared secret not functional. At this point we need to assume that the TPS user has ONE "userCert" registered at this time. --- .../src/com/netscape/certsrv/key/KeyData.java | 17 +- .../cms/servlet/csadmin/ConfigurationUtils.java| 252 - .../cms/servlet/tks/SecureChannelProtocol.java | 3 +- .../com/netscape/cms/servlet/tks/TokenServlet.java | 26 ++- .../server/tks/rest/TPSConnectorService.java | 147 +--- .../server/tps/processor/TPSProcessor.java | 8 +- .../server/tps/rest/TPSInstallerService.java | 12 +- .../com/netscape/cmsutil/crypto/CryptoUtil.java| 157 + 8 files changed, 426 insertions(+), 196 deletions(-) diff --git a/base/common/src/com/netscape/certsrv/key/KeyData.java b/base/common/src/com/netscape/certsrv/key/KeyData.java index 6da4d38..d50c9ec 100644 --- a/base/common/src/com/netscape/certsrv/key/KeyData.java +++ b/base/common/src/com/netscape/certsrv/key/KeyData.java @@ -48,7 +48,8 @@ public class KeyData { @XmlElement Integer size; -String privateData; +@XmlElement +String additionalWrappedPrivateData; public KeyData() { // required for JAXB (defaults) @@ -68,6 +69,14 @@ public class KeyData { this.wrappedPrivateData = wrappedPrivateData; } +public String getAdditionalWrappedPrivateData() { +return additionalWrappedPrivateData; +} + +public void setAdditionalWrappedPrivateData(String additionalWrappedPrivateData) { +this.additionalWrappedPrivateData = additionalWrappedPrivateData; +} + /** * @return the nonceData */ @@ -126,11 +135,5 @@ public class KeyData { this.size = size; } -public String getPrivateData() { -return privateData; -} -public void setPrivateData(String privateData) { -this.privateData = privateData; -} } diff --git a/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java b/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java index 2da4e48..56ee9fa 100644 --- a/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java +++ b/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java @@ -15,7 +15,7 @@ // (C) 2012 Red Hat, Inc. // All rights reserved. // --- END COPYRIGHT BLOCK --- - package com.netscape.cms.servlet.csadmin