From ftweedal at redhat.com Wed Jun 1 04:31:17 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 1 Jun 2016 14:31:17 +1000 Subject: [Pki-devel] [PATCH] 0116 Fix LDAP schema violation when instance name contains '_' In-Reply-To: References: <20160530032501.GD4744@dhcp-40-8.bne.redhat.com> Message-ID: <20160601043116.GV4744@dhcp-40-8.bne.redhat.com> On Tue, May 31, 2016 at 11:07:51AM -0500, Endi Sukma Dewata wrote: > On 5/29/2016 10:25 PM, Fraser Tweedale wrote: > > The attached patch fixes https://fedorahosted.org/pki/ticket/2343 > > > > Cheers, > > Fraser > > ACK. > Thanks Endi! Pushed to master (a40139d5f21139d31b62d3c35002b454131245f1) Cheers, Fraser From ftweedal at redhat.com Wed Jun 1 04:31:41 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 1 Jun 2016 14:31:41 +1000 Subject: [Pki-devel] [PATCH] 0117..0119 Retry key retrieval on failure Message-ID: <20160601043140.GW4744@dhcp-40-8.bne.redhat.com> Hi team, The attached patches implement key retrieval retry with backoff (ticket: https://fedorahosted.org/pki/ticket/2293). Thanks, Fraser -------------- next part -------------- From 93db05ea3cb892be0d19c65fdf7dc9be6759a651 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 31 May 2016 21:38:37 +1000 Subject: [PATCH 117/119] Limit key retrieval to a single thread per CA Before implementing lightweight CA key retrieval retry with exponential backoff, ensure that only one key retriever thread can execute at a time, for each CA. Also make SigningUnit initialisation (initSigUnit) synchronised. Part of: https://fedorahosted.org/pki/ticket/2293 --- .../src/com/netscape/ca/CertificateAuthority.java | 28 +++++++++++++++++----- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java index 5b2f382c29a716f3e72695b7da5406bb85b34845..c2a7d0c907b4dd5774b22cfbb404194da162a535 100644 --- a/base/ca/src/com/netscape/ca/CertificateAuthority.java +++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java @@ -204,6 +204,8 @@ public class CertificateAuthority private static final Map caMap = Collections.synchronizedSortedMap(new TreeMap()); + private static final Map keyRetrieverThreads = + Collections.synchronizedSortedMap(new TreeMap()); protected CertificateAuthority hostCA = null; protected AuthorityID authorityID = null; protected AuthorityID authorityParentID = null; @@ -1460,7 +1462,7 @@ public class CertificateAuthority /** * init CA signing unit & cert chain. */ - private boolean initSigUnit(boolean retrieveKeys) + private synchronized boolean initSigUnit(boolean retrieveKeys) throws EBaseException { try { // init signing unit @@ -1491,11 +1493,16 @@ public class CertificateAuthority CMS.debug("CA signing key and cert not (yet) present in NSSDB"); signingUnitException = e; if (retrieveKeys == true) { - CMS.debug("Starting KeyRetrieverRunner thread"); - new Thread( - new KeyRetrieverRunner(this), - "KeyRetrieverRunner-" + authorityID - ).start(); + if (!keyRetrieverThreads.containsKey(authorityID)) { + CMS.debug("Starting KeyRetrieverRunner thread"); + Thread t = new Thread( + new KeyRetrieverRunner(this), + "KeyRetrieverRunner-" + authorityID); + t.start(); + keyRetrieverThreads.put(authorityID, t); + } else { + CMS.debug("KeyRetriever thread already running for authority " + authorityID); + } } return false; } @@ -3180,6 +3187,15 @@ public class CertificateAuthority } public void run() { + try { + _run(); + } finally { + // remove self from tracker + keyRetrieverThreads.remove(ca.authorityID); + } + } + + private void _run() { String KR_CLASS_KEY = "features.authority.keyRetrieverClass"; String className = null; try { -- 2.5.5 -------------- next part -------------- From f6eed44501b6b65f1da1e32c9c6755db180b8776 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 31 May 2016 22:20:06 +1000 Subject: [PATCH 118/119] Don't update obsolete CertificateAuthority after key retrieval If additional LDAP events are processed for a lightweight CA while key retrieval proceeds in another thread, when retrieval is complete, the KeyRetrieverRunner reinitialises the signing unit of a stale object. Instead of holding onto a CertificateAuthority, hold onto the AuthorityID and look it up afresh when ready to reinitialise its SigningUnit. Part of: https://fedorahosted.org/pki/ticket/2293 --- .../src/com/netscape/ca/CertificateAuthority.java | 31 +++++++++++++++++----- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java index c2a7d0c907b4dd5774b22cfbb404194da162a535..289ab7ac703fcd7e35b11b589f0dfb2b57488006 100644 --- a/base/ca/src/com/netscape/ca/CertificateAuthority.java +++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java @@ -1496,7 +1496,7 @@ public class CertificateAuthority if (!keyRetrieverThreads.containsKey(authorityID)) { CMS.debug("Starting KeyRetrieverRunner thread"); Thread t = new Thread( - new KeyRetrieverRunner(this), + new KeyRetrieverRunner(authorityID, mNickname, authorityKeyHosts), "KeyRetrieverRunner-" + authorityID); t.start(); keyRetrieverThreads.put(authorityID, t); @@ -3180,10 +3180,15 @@ public class CertificateAuthority } private class KeyRetrieverRunner implements Runnable { - private CertificateAuthority ca; + private AuthorityID aid; + private String nickname; + private Collection hosts; - public KeyRetrieverRunner(CertificateAuthority ca) { - this.ca = ca; + public KeyRetrieverRunner( + AuthorityID aid, String nickname, Collection hosts) { + this.aid = aid; + this.nickname = nickname; + this.hosts = hosts; } public void run() { @@ -3191,7 +3196,7 @@ public class CertificateAuthority _run(); } finally { // remove self from tracker - keyRetrieverThreads.remove(ca.authorityID); + keyRetrieverThreads.remove(aid); } } @@ -3226,7 +3231,7 @@ public class CertificateAuthority KeyRetriever.Result krr = null; try { - krr = kr.retrieveKey(ca.mNickname, ca.authorityKeyHosts); + krr = kr.retrieveKey(nickname, hosts); } catch (Throwable e) { CMS.debug("Caught exception during execution of KeyRetriever.retrieveKey"); CMS.debug(e); @@ -3254,16 +3259,28 @@ public class CertificateAuthority CryptoUtil.importPKIArchiveOptions( token, unwrappingKey, pubkey, paoData); - cert = manager.importUserCACertPackage(certBytes, ca.mNickname); + cert = manager.importUserCACertPackage(certBytes, nickname); } catch (Throwable e) { CMS.debug("Caught exception during cert/key import"); CMS.debug(e); return; } + CertificateAuthority ca; boolean initSigUnitSucceeded = false; try { CMS.debug("Reinitialising SigningUnit"); + + /* While we were retrieving the key and cert, the + * CertificateAuthority instance in the caMap might + * have been replaced, so look it up afresh. + */ + ca = (CertificateAuthority) getCA(aid); + if (ca == null) { + CMS.debug("Authority is no longer in caMap; returning."); + return; + } + // re-init signing unit, but avoid triggering // key replication if initialisation fails again // for some reason -- 2.5.5 -------------- next part -------------- From de46a100698c77168467d72b16823de2630dda55 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 1 Jun 2016 09:46:56 +1000 Subject: [PATCH 119/119] Retry failed key retrieval with backoff If lightweight CA key retrieval fails, retry the retieval after a delay of 10 seconds initially, increasing thereafter. Fixes: https://fedorahosted.org/pki/ticket/2293 --- .../src/com/netscape/ca/CertificateAuthority.java | 58 ++++++++++++++++------ 1 file changed, 44 insertions(+), 14 deletions(-) diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java index 289ab7ac703fcd7e35b11b589f0dfb2b57488006..1505b9951cffae2cae8dcc715bb60fa56b78cae8 100644 --- a/base/ca/src/com/netscape/ca/CertificateAuthority.java +++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java @@ -3193,21 +3193,39 @@ public class CertificateAuthority public void run() { try { - _run(); + long d = 10000; // initial delay of 10 seconds + while (!_run()) { + CMS.debug("Retrying in " + d / 1000 + " seconds"); + try { + Thread.sleep(d); + } catch (InterruptedException e) { + break; + } + d += d / 2; // back off + } } finally { // remove self from tracker keyRetrieverThreads.remove(aid); } } - private void _run() { + /** + * Main routine of key retrieval and key import. + * + * @return false if retrieval should be retried, or true if + * the process is "done". Note that a result of true + * does not necessarily imply that the process fully + * completed. See comments at sites of 'return true;' + * below. + */ + private boolean _run() { String KR_CLASS_KEY = "features.authority.keyRetrieverClass"; String className = null; try { className = CMS.getConfigStore().getString(KR_CLASS_KEY); } catch (EBaseException e) { CMS.debug("Unable to read key retriever class from CS.cfg: " + e); - return; + return false; } KeyRetriever kr = null; @@ -3218,15 +3236,15 @@ public class CertificateAuthority } catch (ClassNotFoundException e) { CMS.debug("Could not find class: " + className); CMS.debug(e); - return; + return false; } catch (ClassCastException e) { CMS.debug("Class is not an instance of KeyRetriever: " + className); CMS.debug(e); - return; + return false; } catch (InstantiationException | IllegalAccessException e) { CMS.debug("Could not instantiate class: " + className); CMS.debug(e); - return; + return false; } KeyRetriever.Result krr = null; @@ -3235,12 +3253,12 @@ public class CertificateAuthority } catch (Throwable e) { CMS.debug("Caught exception during execution of KeyRetriever.retrieveKey"); CMS.debug(e); - return; + return false; } if (krr == null) { CMS.debug("KeyRetriever did not return a result."); - return; + return false; } CMS.debug("Importing key and cert"); @@ -3263,7 +3281,7 @@ public class CertificateAuthority } catch (Throwable e) { CMS.debug("Caught exception during cert/key import"); CMS.debug(e); - return; + return false; } CertificateAuthority ca; @@ -3277,8 +3295,11 @@ public class CertificateAuthority */ ca = (CertificateAuthority) getCA(aid); if (ca == null) { - CMS.debug("Authority is no longer in caMap; returning."); - return; + /* We got the key, but the authority has been + * deleted. Do not retry. + */ + CMS.debug("Authority was deleted; returning."); + return true; } // re-init signing unit, but avoid triggering @@ -3289,22 +3310,31 @@ public class CertificateAuthority } catch (Throwable e) { CMS.debug("Caught exception during SigningUnit re-init"); CMS.debug(e); - return; + return false; } if (!initSigUnitSucceeded) { CMS.debug("Failed to re-init SigningUnit"); - return; + return false; } CMS.debug("Adding self to authorityKeyHosts attribute"); try { ca.addInstanceToAuthorityKeyHosts(); } catch (Throwable e) { + /* We retrieved key, imported it, and successfully + * re-inited the signing unit. The only thing that + * failed was adding this host to the list of hosts + * that possess the key. This is unlikely, and the + * key is available elsewhere, so no need to retry. + */ CMS.debug("Failed to add self to authorityKeyHosts"); CMS.debug(e); - return; + return true; } + + /* All good! */ + return true; } } -- 2.5.5 From ftweedal at redhat.com Wed Jun 1 04:45:59 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 1 Jun 2016 14:45:59 +1000 Subject: [Pki-devel] [PATCH] 0120..0121 Remove pki-ipa-retrieve-key script Message-ID: <20160601044559.GX4744@dhcp-40-8.bne.redhat.com> G'day comrades, Please review the attached two patches, which... (Patch 0120) - provide for passing of configuration (from CS.cfg) to KeyRetriever implementations - generalise IPACustodiaKeyRetriever to ExternalProcessKeyRetriever, which executes a configured executable rather than a hardcoded one (Patch 0121) - remove pki-ipa-retrieve-key script; it is being moved to FreeIPA repo Cheers, Fraser -------------- next part -------------- From 34fe6c81202a4ba7d3f3788193fe3d93faeaceff Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 31 May 2016 16:10:05 +1000 Subject: [PATCH 120/121] Lightweight CAs: generalise subprocess-based key retrieval The IPACustodiaKeyRetriever doesn't really do anything specific to IPA or Custodia; it merely executes a certain executable with a particular behavioural contract. Add support for passing configuration to KeyRetriever instances, and rename IPACustodiaKeyRetriever to ExternalProcessKeyRetriever, updating it to use the "executable" config property instead of a hardcoded filename. Part of: https://fedorahosted.org/pki/ticket/1625 --- .../src/com/netscape/ca/CertificateAuthority.java | 24 +++++++++++++--- ...iever.java => ExternalProcessKeyRetriever.java} | 33 ++++++++++++++++------ 2 files changed, 45 insertions(+), 12 deletions(-) rename base/ca/src/com/netscape/ca/{IPACustodiaKeyRetriever.java => ExternalProcessKeyRetriever.java} (71%) diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java index 5b2f382c29a716f3e72695b7da5406bb85b34845..6ba9ffed3736f38e4ee1fbf3fb058fdf62dac9f9 100644 --- a/base/ca/src/com/netscape/ca/CertificateAuthority.java +++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java @@ -24,6 +24,7 @@ import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.io.PrintStream; +import java.lang.reflect.InvocationTargetException; import java.math.BigInteger; import java.security.KeyPair; import java.security.MessageDigest; @@ -3181,6 +3182,8 @@ public class CertificateAuthority public void run() { String KR_CLASS_KEY = "features.authority.keyRetrieverClass"; + String KR_CONFIG_KEY = "features.authority.keyRetrieverConfig"; + String className = null; try { className = CMS.getConfigStore().getString(KR_CLASS_KEY); @@ -3189,11 +3192,23 @@ public class CertificateAuthority return; } + IConfigStore krConfig = CMS.getConfigStore().getSubStore(KR_CONFIG_KEY); + KeyRetriever kr = null; try { - kr = Class.forName(className) - .asSubclass(KeyRetriever.class) - .newInstance(); + Class cls = + Class.forName(className).asSubclass(KeyRetriever.class); + + // If there is an accessible constructor that takes + // an IConfigStore, invoke that; otherwise invoke + // the nullary constructor. + try { + kr = cls.getDeclaredConstructor(IConfigStore.class) + .newInstance(krConfig); + } catch (NoSuchMethodException | SecurityException + | IllegalAccessException e) { + kr = cls.newInstance(); + } } catch (ClassNotFoundException e) { CMS.debug("Could not find class: " + className); CMS.debug(e); @@ -3202,7 +3217,8 @@ public class CertificateAuthority CMS.debug("Class is not an instance of KeyRetriever: " + className); CMS.debug(e); return; - } catch (InstantiationException | IllegalAccessException e) { + } catch (InstantiationException | IllegalAccessException + | IllegalArgumentException | InvocationTargetException e) { CMS.debug("Could not instantiate class: " + className); CMS.debug(e); return; diff --git a/base/ca/src/com/netscape/ca/IPACustodiaKeyRetriever.java b/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java similarity index 71% rename from base/ca/src/com/netscape/ca/IPACustodiaKeyRetriever.java rename to base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java index 4a162d3702fccc19dfef792a5213c653286930f3..6aee9716e1e5953018ed4c3f3316c9b7d4c88a45 100644 --- a/base/ca/src/com/netscape/ca/IPACustodiaKeyRetriever.java +++ b/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java @@ -27,13 +27,32 @@ import org.apache.commons.io.IOUtils; import org.apache.commons.lang.ArrayUtils; import com.netscape.certsrv.apps.CMS; +import com.netscape.certsrv.base.EBaseException; +import com.netscape.certsrv.base.EPropertyNotFound; +import com.netscape.certsrv.base.IConfigStore; + + +public class ExternalProcessKeyRetriever implements KeyRetriever { + protected String executable; + + public ExternalProcessKeyRetriever(IConfigStore config) { + if (config == null) + throw new IllegalArgumentException("Missing config"); + + try { + this.executable = config.getString("executable"); + } catch (EPropertyNotFound e) { + throw new IllegalArgumentException("Missing 'executable' config property"); + } catch (EBaseException e) { + throw new RuntimeException(e); + } + } -public class IPACustodiaKeyRetriever implements KeyRetriever { public Result retrieveKey(String nickname, Collection hostPorts) { - CMS.debug("Running IPACustodiaKeyRetriever"); + CMS.debug("Running ExternalProcessKeyRetriever"); Stack command = new Stack<>(); - command.push("/usr/libexec/pki-ipa-retrieve-key"); + command.push(this.executable); command.push(nickname); for (String hostPort : hostPorts) { @@ -47,11 +66,9 @@ public class IPACustodiaKeyRetriever implements KeyRetriever { if (exitValue != 0) continue; - /* Custodia returns a PEM-encoded certificate and a - * base64-encoded PKIArchiveOptions containing the - * wrapped private key. These values are output by - * the Python 'pki-ipa-retrieve-key' program, - * separated by a null byte (password first) + /* Read a PEM-encoded certificate and a base64-encoded + * PKIArchiveOptions containing the wrapped private key, + * separated by a null byte. */ byte[] output = IOUtils.toByteArray(p.getInputStream()); int splitIndex = ArrayUtils.indexOf(output, (byte) 0); -- 2.5.5 -------------- next part -------------- From 6781eb1365660963deb3df2e0dcd5d45ba48372f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 31 May 2016 19:33:17 +1000 Subject: [PATCH 121/121] Lightweight CAs: remove pki-ipa-retrieve-key script For the benefit of code locality and subsequent to the generalisation of IPACustodiaKeyRetriever to ExternalProcessKeyRetriever, the pki-ipa-retrieve-key script is being moved to the FreeIPA codebase. Part of: https://fedorahosted.org/pki/ticket/1625 --- base/server/CMakeLists.txt | 11 -------- base/server/libexec/pki-ipa-retrieve-key | 45 -------------------------------- specs/pki-core.spec | 1 - 3 files changed, 57 deletions(-) delete mode 100755 base/server/libexec/pki-ipa-retrieve-key diff --git a/base/server/CMakeLists.txt b/base/server/CMakeLists.txt index 9e5b27833c8d023e63320c43d64ad64b0055c254..5a6aea96a2317655fb454967f9f218020443bcb8 100644 --- a/base/server/CMakeLists.txt +++ b/base/server/CMakeLists.txt @@ -81,17 +81,6 @@ install( install( DIRECTORY - libexec/ - DESTINATION - ${LIBEXEC_INSTALL_DIR} - FILE_PERMISSIONS - OWNER_EXECUTE OWNER_WRITE OWNER_READ - GROUP_EXECUTE GROUP_READ - WORLD_EXECUTE WORLD_READ -) - -install( - DIRECTORY upgrade DESTINATION ${DATA_INSTALL_DIR}/server/ diff --git a/base/server/libexec/pki-ipa-retrieve-key b/base/server/libexec/pki-ipa-retrieve-key deleted file mode 100755 index 301f818b859577ef1a861bc7a855b6103a6f3af8..0000000000000000000000000000000000000000 --- a/base/server/libexec/pki-ipa-retrieve-key +++ /dev/null @@ -1,45 +0,0 @@ -#!/usr/bin/python - -from __future__ import print_function - -import ConfigParser -import base64 -import os -import sys - -from jwcrypto.common import json_decode - -from ipalib import constants -from ipaplatform.paths import paths -from ipapython.secrets.client import CustodiaClient - -conf = ConfigParser.ConfigParser() -conf.read(paths.IPA_DEFAULT_CONF) -hostname = conf.get('global', 'host') -realm = conf.get('global', 'realm') - -keyname = "ca_wrapped/" + sys.argv[1] -servername = sys.argv[2] - -service = constants.PKI_GSSAPI_SERVICE_NAME -client_keyfile = os.path.join(paths.PKI_TOMCAT, service + '.keys') -client_keytab = os.path.join(paths.PKI_TOMCAT, service + '.keytab') - -client = CustodiaClient( - client=hostname, server=servername, realm=realm, - ldap_uri="ldaps://" + hostname, - client_servicename=service, - keyfile=client_keyfile, keytab=client_keytab, - ) - -result_json = client.fetch_key(keyname, store=False) -result = json_decode(result_json) -certificate = result["certificate"] -wrapped_key = base64.b64decode(result["wrapped_key"]) - -# Custodia returns a PEM-encoded certificate and a base64-encoded -# DER PKIArchiveOptions object. Output these values, separated by a -# null byte (certificate first), to be read by the Java -# IPACustodiaKeyRetriever that invoked this program. - -print(certificate, wrapped_key, sep='\0', end='') diff --git a/specs/pki-core.spec b/specs/pki-core.spec index 04baec4f8f4a4aac1da793873e55e422672800c7..cdd087c11f0d03532bf2713db17cadcbd59bc031 100644 --- a/specs/pki-core.spec +++ b/specs/pki-core.spec @@ -1016,7 +1016,6 @@ systemctl daemon-reload %{_sbindir}/pki-server %{_sbindir}/pki-server-nuxwdog %{_sbindir}/pki-server-upgrade -%{_libexecdir}/pki-ipa-retrieve-key %{python2_sitelib}/pki/server/ %dir %{_datadir}/pki/deployment %{_datadir}/pki/deployment/config/ -- 2.5.5 From mharmsen at redhat.com Wed Jun 1 17:19:51 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 1 Jun 2016 11:19:51 -0600 Subject: [Pki-devel] [PATCH] Fix unknown TKS host and port error during TPS removal Message-ID: <574F1937.4010207@redhat.com> Please review the attached patch which addresses the following ticket: * PKI TRAC #1677 - Pkidestroy of a TPS instance installed in a shared tomcat throws error. Without the patch: # pkidestroy Subsystem (CA/KRA/OCSP/TKS/TPS) [CA]: TPS Instance [pki-tomcat]: Begin uninstallation (Yes/No/Quit)? Yes Log file: /var/log/pki/pki-tps-destroy.20160601102651.log Loading deployment configuration from /var/lib/pki/pki-tomcat/tps/registry/tps/deployment.cfg. Uninstalling TPS from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ....... Failed to update TPS connector on TKS pkidestroy : ERROR ....... TKS Host or Port is undefined Uninstallation complete. With the patch: # pkidestroy Subsystem (CA/KRA/OCSP/TKS/TPS) [CA]: TPS Instance [pki-tomcat]: Begin uninstallation (Yes/No/Quit)? Yes Log file: /var/log/pki/pki-tps-destroy.20160601110057.log Loading deployment configuration from /var/lib/pki/pki-tomcat/tps/registry/tps/deployment.cfg. Uninstalling TPS from /var/lib/pki/pki-tomcat. Uninstallation complete. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20160601-Fix-unknown-TKS-host-and-port-connector-error.patch Type: text/x-patch Size: 1923 bytes Desc: not available URL: From tjaalton at ubuntu.com Wed Jun 1 20:52:12 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 1 Jun 2016 23:52:12 +0300 Subject: [Pki-devel] [Pki-users] Announcing the Release of Dogtag 10.3.1 In-Reply-To: <7b706232-14e4-4953-47f1-32a428d4c594@redhat.com> References: <7b706232-14e4-4953-47f1-32a428d4c594@redhat.com> Message-ID: <574F4AFC.7010405@ubuntu.com> On 24.05.2016 19:23, Matthew Harmsen wrote: > The Dogtag team is proud to announce the release of Dogtag 10.3.1. > > Builds are available for Fedora 24. > > == Build Versions == > > * > > dogtag-pki-10.3.1-1 > > > * > > dogtag-pki-theme-10.3.1-1 > > > * > > pki-console-10.3.1-1 > > > * > > pki-core-10.3.1-1 > > > == Upgrade Notes == > > Simply use dnf to update existing packages. Hi, Are there any release notes for 10.3.x? -- t From jmagne at redhat.com Wed Jun 1 22:13:53 2016 From: jmagne at redhat.com (John Magne) Date: Wed, 1 Jun 2016 18:13:53 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0069-Show-KeyOwner-info-when-viewing-recovery-requests.patch In-Reply-To: <917977919.11034767.1464819157194.JavaMail.zimbra@redhat.com> Message-ID: <807574163.11035031.1464819233747.JavaMail.zimbra@redhat.com> Show KeyOwner info when viewing recovery requests. This simple fix will grab the subject info out of the cert associated with either pending or complete recovery requests being viewed in the KRA UI. For example: KeyOwner: UID=jmagne, O=Token Key User Will be displayed. Have seen this display for both pending and completed recovery requests. This simple fix should be good enough for this round, despite the bug asking about agent info and such. Those enhancements for later. Ticket : Ticket #1512 : Key owner info missing from the Search results of Recovery request -------------- next part -------------- A non-text attachment was scrubbed... Name: 0069-Show-KeyOwner-info-when-viewing-recovery-requests.patch Type: text/x-patch Size: 2396 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 2 04:09:52 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 1 Jun 2016 23:09:52 -0500 Subject: [Pki-devel] db changes In-Reply-To: <1464686699.5290.3.camel@redhat.com> References: <1464686699.5290.3.camel@redhat.com> Message-ID: On 5/31/2016 4:24 AM, Ade Lee wrote: > Hey guys, > > I had some time during layovers/flights and threw a couple of ideas > together about how to handle the DB changes we have to perform for fine > grained authz and sub CAs, and other future changes .. > > http://pki.fedoraproject.org/wiki/Tracking_db_migrations > > Please take a look and comment. > Thanks, > Ade This is a bit complex, but here's my initial thoughts: 1. I think we need more fine-grained trackers due to differences in how the DS contents are shared and replicated. Please take a look at this page: http://pki.fedoraproject.org/wiki/DS_Deployment_Scenarios a) There should be a separate tracker for DS schema (e.g. cn=schema,cn=trackers) since the schema is shared by all backends in the same DS instance (unless the subsystems use separate DS instances) and it's replicated to all clones. b) There should be a separate tracker for DS configuration (e.g. cn=config,cn=,cn=trackers) since the configuration is shared with all backends in the same DS instance (unless the subsystems use separate DS instances), but it's not replicated to other clones. c) There should be a separate tracker for each subsystem subtree (e.g. cn=ca,cn=subtrees,cn=trackers) since the subtree is not shared with other backends, but it's replicated to all clones. d) There should be a separate tracker for each subsystem indexes (e.g. cn=ca,cn=indexes,cn=,cn=trackers) since the indexes are not shared with other backends and they are not replicated to other clones. 2. I don't think global updates have to necessarily happen before local updates. The upgrade scripts should have their own sequence number to allow flexible execution order. The version numbers stored in the trackers should be independent of each other, but the upgrade scripts can enforce certain dependency. For example: 01-UpdateSchema 02-UpdateSubtreeToUseTheNewSchema Script #1 will do something like this: if schema.version < MIN_SCHEMA_VERSION: update_schema() Script #2 will do something like this: if schema.version >= MIN_SCHEMA_VERSION: update_subtree() So if the schema was already updated while upgrading another subsystem, the schema will not be updated again since the version number may already meet the minimum requirement. 3. Although we don't have a top-level DN now, different PKI subsystems using the same DS instance can share the same trackers stored in one of the subsystem subtree. The base DN of the trackers can be stored in a file in each PKI instance/subsystem, so it can be customized depending on the deployment scenario. When we have the top-level DN in the future, the trackers can be moved there too. 4. In the future there we might want to keep track of the optional security upgrades as well: https://fedorahosted.org/pki/ticket/1135 As shown in the example, at some point we might want to remove obsolete algorithm (e.g. SHA1withRSA), but we cannot do that automatically since some people might still depend specifically on it. So these types of upgrades should be optional, they should not block other upgrades, and the server should continue to function even without these upgrades. However, we need to keep track of them to remind people that in the future they will be required to do the upgrade. This can be done by adding tracking entries under one of the above trackers depending on the scope. For example: cn=Remove SHA1withRSA from caAdminCert profile, cn=ca,cn=subtrees,cn=trackers assuming the profiles are in LDAP, or cn=Remove SHA1withRSA from caAdminCert profile, cn=ca,cn=config,cn=,cn=trackers if the profiles are still stored in locally in the CA subsystem that uses the above DS instance. Nothing to change in the design, but we just need to make sure this can be done in the future. -- Endi S. Dewata From alee at redhat.com Thu Jun 2 13:50:00 2016 From: alee at redhat.com (Ade Lee) Date: Thu, 02 Jun 2016 09:50:00 -0400 Subject: [Pki-devel] [PATCH] 315-319 KRA realm related patches Message-ID: <1464875400.7327.2.camel@redhat.com> Patch descriptions (in reverse order). The final patch will need some discussion. Please review, Ade *********************************************** commit 4a1fb1e678d0024d9ee51fcda0d83f74f1715f4b Author: Ade Lee Date: Thu Jun 2 09:41:35 2016 -0400 Modify pki-server db-upgrade to do realm related upgrades Tickets 2320, 2319 commit ed3e2da4c598bf4cec89bec8e20a23ab6d82013c Author: Ade Lee Date: Fri May 27 14:01:59 2016 -0400 New VLV indexes for KRA including realm commit 1a2947fed2f7cd2cc32fa810ab77d64bf3acb821 Author: Ade Lee Date: Thu May 26 00:48:39 2016 -0400 Fix legacy servlets to check realm when requesting recovery commit 483f9b2066110c3b8d4598e3afe1a9508bddbbb7 Author: Ade Lee Date: Wed May 25 18:53:22 2016 -0400 Change legacy requests servlet to check realm The legacy KRA servlet has been modified to check the realm if present in the request, or only return non-realm requests if not present. No attempt is made to fix the error reporting of the servlet. As such, an authz failure due to the realm check is handled in the same way that other authz failures are handled. commit 6c52845955315ca8842290d41c826c26aa037eb3 Author: Ade Lee Date: Wed May 25 18:10:59 2016 -0400 Fix old KRA servlets to check realm The old KRA servlets to list and display keys do not go through the same code paths as the REST API. Therefore, they do not check the authz realm. This patch adds the relevant code. No attempt is made to fix the error handling of the old servlets. the long term solution for this is to deprecate the old servlets and make the UI use the REST API instead. Therefore, authz failures due to realm checks are handled in the same way as other authz changes. From alee at redhat.com Thu Jun 2 13:51:12 2016 From: alee at redhat.com (Ade Lee) Date: Thu, 02 Jun 2016 09:51:12 -0400 Subject: [Pki-devel] [PATCH] 315-319 KRA realm related patches In-Reply-To: <1464875400.7327.2.camel@redhat.com> References: <1464875400.7327.2.camel@redhat.com> Message-ID: <1464875472.7327.4.camel@redhat.com> And now with the patches .. On Thu, 2016-06-02 at 09:50 -0400, Ade Lee wrote: > Patch descriptions (in reverse order). > > The final patch will need some discussion. Please review, > > Ade > > *********************************************** > commit 4a1fb1e678d0024d9ee51fcda0d83f74f1715f4b > Author: Ade Lee > Date: Thu Jun 2 09:41:35 2016 -0400 > > Modify pki-server db-upgrade to do realm related upgrades > > Tickets 2320, 2319 > > commit ed3e2da4c598bf4cec89bec8e20a23ab6d82013c > Author: Ade Lee > Date: Fri May 27 14:01:59 2016 -0400 > > New VLV indexes for KRA including realm > > commit 1a2947fed2f7cd2cc32fa810ab77d64bf3acb821 > Author: Ade Lee > Date: Thu May 26 00:48:39 2016 -0400 > > Fix legacy servlets to check realm when requesting recovery > > commit 483f9b2066110c3b8d4598e3afe1a9508bddbbb7 > Author: Ade Lee > Date: Wed May 25 18:53:22 2016 -0400 > > Change legacy requests servlet to check realm > > The legacy KRA servlet has been modified to check the realm > if present in the request, or only return non-realm requests > if not present. > > No attempt is made to fix the error reporting of the servlet. > As such, an authz failure due to the realm check is handled > in the same way that other authz failures are handled. > > commit 6c52845955315ca8842290d41c826c26aa037eb3 > Author: Ade Lee > Date: Wed May 25 18:10:59 2016 -0400 > > Fix old KRA servlets to check realm > > The old KRA servlets to list and display keys do not go through > the same code paths as the REST API. Therefore, they do not > check the authz realm. > > This patch adds the relevant code. No attempt is made to fix the > error handling of the old servlets. the long term solution for > this > is to deprecate the old servlets and make the UI use the REST API > instead. Therefore, authz failures due to realm checks are > handled > in the same way as other authz changes. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0315-Fix-old-KRA-servlets-to-check-realm.patch Type: text/x-patch Size: 16318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0316-Change-legacy-requests-servlet-to-check-realm.patch Type: text/x-patch Size: 3563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0317-Fix-legacy-servlets-to-check-realm-when-requesting-r.patch Type: text/x-patch Size: 11620 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0318-New-VLV-indexes-for-KRA-including-realm.patch Type: text/x-patch Size: 5214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0319-Modify-pki-srever-db-upgrade-to-do-realm-related-upg.patch Type: text/x-patch Size: 11817 bytes Desc: not available URL: From alee at redhat.com Thu Jun 2 14:17:39 2016 From: alee at redhat.com (Ade Lee) Date: Thu, 02 Jun 2016 10:17:39 -0400 Subject: [Pki-devel] [PATCH] 760 Fixed invalid TPS VLV indexes. In-Reply-To: References: Message-ID: <1464877059.7327.5.camel@redhat.com> ACK On Fri, 2016-05-27 at 17:53 -0500, Endi Sukma Dewata wrote: > The TPS VLV indexes have been fixed to use the correct vlvScope > (i.e. one level). The unsupported minus sign in vlvSort and the > redundant vlvEnabled have been removed. > > https://fedorahosted.org/pki/ticket/2342 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Jun 2 15:52:24 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 10:52:24 -0500 Subject: [Pki-devel] [PATCH] 754-755 Fixed problem submitting renewal request. In-Reply-To: <1dcbf73e-74ae-e5cd-7524-6e148b509715@redhat.com> References: <1dcbf73e-74ae-e5cd-7524-6e148b509715@redhat.com> Message-ID: <0ed512cb-faa5-d6a9-518d-5d17f80e743c@redhat.com> On 5/24/2016 11:55 AM, Endi Sukma Dewata wrote: > Attached are patches to fix a problem with submitting renewal request. > > https://fedorahosted.org/pki/ticket/999 This was conditionally ACKed by jmagne (thanks!). It's been tested to work with the UI and CLI with a minor revision. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Jun 2 16:29:12 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 11:29:12 -0500 Subject: [Pki-devel] [PATCH] 760 Fixed invalid TPS VLV indexes. In-Reply-To: <1464877059.7327.5.camel@redhat.com> References: <1464877059.7327.5.camel@redhat.com> Message-ID: <960ffa66-579c-fca5-5040-bbf180553297@redhat.com> On 6/2/2016 9:17 AM, Ade Lee wrote: > ACK Thanks! Also ACKed by jmagne. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Jun 2 19:10:26 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 14:10:26 -0500 Subject: [Pki-devel] [PATCH] 315-319 KRA realm related patches In-Reply-To: <1464875472.7327.4.camel@redhat.com> References: <1464875400.7327.2.camel@redhat.com> <1464875472.7327.4.camel@redhat.com> Message-ID: <7a425667-5a56-daea-2909-38c6b6774f32@redhat.com> On 6/2/2016 8:51 AM, Ade Lee wrote: > And now with the patches .. > > On Thu, 2016-06-02 at 09:50 -0400, Ade Lee wrote: >> Patch descriptions (in reverse order). >> >> The final patch will need some discussion. Please review, >> >> Ade Some comments: 1. In SrchKey and SrchKeyForRecovery the check probably should have been like this (no closing paren): if (filter.contains("(realm=")) { 2. If a realm is specified, I suppose it won't match any of the VLV indexes. Do the queries still work correctly without a matching VLV? 3. Could you document how to run the upgrade command in this page? http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x Note that there are still some manual upgrade procedures that also need to be executed as documented in that page. 4. In PKISubsystem.open_database() can we use bind_dn and bind_password parameter names instead of user and password (it's a DN not a user ID)? Also in DBUpgrade should we use -D, -w, and -Z for consistency with DS tools? 5. The gnu_getopt() is called with "server_id=". I think it should be "server-id=". But since it actually contains the DS instance name maybe we should use "ds-instance=" instead? 6. In the DBUpgrade.modify_kra_vlv() the os.unlink(ldif_file) probably should be moved into the finally clause above it to ensure the temporary file is deleted in all cases. Alternatively the code could be written like this: with NamedTemporaryFile() as ldif_file: # do everything with the ldif_file here 7. In DBUpgrade.modify_schema() why not use subsystem.open_database() instead of ldapmodify? That will ensure it uses the same mechanism to connect to the LDAP server. 8. Also the DBUpgrade.modify_schema() is ignoring all schema update failures. I think we can only ignore the case where the new schema is already added. In other cases the upgrade should fail since the subsequent upgrades may depend on it. 9. I think DBUpgrade.create_realm_index() should only execute if there's a KRA subsystem in the instance. The code right now creates the index in the first subsystem's database which may not be a KRA. subsystem = instance.subsystems[0] 10. The DBUpgrade uses db2index.pl to rebuild the indexes which means the LDAP server must run locally. To support remote LDAP server I think we need to use reindex task. We have indextasks.ldif and vlvtasks.ldif that can be used for this. See also: http://pki.fedoraproject.org/wiki/DS_Database_Indexes 11. The DBUpgrade should not ignore reindex failures since subsequent upgrades may depend on it. 12. There's a typo in the last patch's commit description. -- Endi S. Dewata From jmagne at redhat.com Thu Jun 2 22:18:29 2016 From: jmagne at redhat.com (John Magne) Date: Thu, 2 Jun 2016 18:18:29 -0400 (EDT) Subject: [Pki-devel] [PATCH] Fix unknown TKS host and port error during TPS removal In-Reply-To: <574F1937.4010207@redhat.com> References: <574F1937.4010207@redhat.com> Message-ID: <574208072.11761665.1464905909851.JavaMail.zimbra@redhat.com> ACK ----- Original Message ----- From: "Matthew Harmsen" To: "pki-devel" Sent: Wednesday, June 1, 2016 10:19:51 AM Subject: [Pki-devel] [PATCH] Fix unknown TKS host and port error during TPS removal Please review the attached patch which addresses the following ticket: * PKI TRAC #1677 - Pkidestroy of a TPS instance installed in a shared tomcat throws error. Without the patch: # pkidestroy Subsystem (CA/KRA/OCSP/TKS/TPS) [CA]: TPS Instance [pki-tomcat]: Begin uninstallation (Yes/No/Quit)? Yes Log file: /var/log/pki/pki-tps-destroy.20160601102651.log Loading deployment configuration from /var/lib/pki/pki-tomcat/tps/registry/tps/deployment.cfg. Uninstalling TPS from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ....... Failed to update TPS connector on TKS pkidestroy : ERROR ....... TKS Host or Port is undefined Uninstallation complete. With the patch: # pkidestroy Subsystem (CA/KRA/OCSP/TKS/TPS) [CA]: TPS Instance [pki-tomcat]: Begin uninstallation (Yes/No/Quit)? Yes Log file: /var/log/pki/pki-tps-destroy.20160601110057.log Loading deployment configuration from /var/lib/pki/pki-tomcat/tps/registry/tps/deployment.cfg. Uninstalling TPS from /var/lib/pki/pki-tomcat. Uninstallation complete. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Thu Jun 2 23:52:59 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 2 Jun 2016 16:52:59 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0127-Ticket-2271-Part2-TMS-removing-reducing-debug-log-pr.patch Message-ID: <5750C6DB.3000901@redhat.com> Ticket #2271 Part2:TMS:removing/reducing debug log printout of data This patch comments out unneeded data in TMS debug logs (TPS&TKS); It reduces the size of the debug logs by a lot. Note that for ease of later development debugging, the debug lines are commented out instead of being removed Testing was done in * formatting * formatting with key upgrade * enrollment with server side key generation * enrollment * enrollment with key recovery thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0127-Ticket-2271-Part2-TMS-removing-reducing-debug-log-pr.patch Type: text/x-patch Size: 71197 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 2 23:59:03 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 18:59:03 -0500 Subject: [Pki-devel] [PATCH] 757 Added TPS token state transition validation. In-Reply-To: References: <494e60e9-4394-3ae6-5ce2-755a7dc7edf7@redhat.com> Message-ID: <4aa5d887-552c-5160-435b-464ba473433e@redhat.com> On 5/27/2016 5:52 PM, Endi Sukma Dewata wrote: > On 5/25/2016 10:34 PM, Endi Sukma Dewata wrote: >> The TPSSubsystem has been modified to load and validate the token >> state transition lists during initialization. If any of the lists >> is empty or any of the transitions is invalid, the initialization >> will fail and the subsystem will not start. >> >> https://fedorahosted.org/pki/ticket/2334 > > Rebased. ACKed by jmagne (thanks!) with small revision. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Jun 3 00:10:49 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 19:10:49 -0500 Subject: [Pki-devel] [PATCH] 0110 Lightweight CAs: remove redundant deletePrivateKey invocation In-Reply-To: <20160516032609.GB1323@dhcp-40-8.bne.redhat.com> References: <20160516032609.GB1323@dhcp-40-8.bne.redhat.com> Message-ID: On 5/15/2016 10:26 PM, Fraser Tweedale wrote: > Hi team, > > The attached patch fixes https://fedorahosted.org/pki/ticket/1640. > > Cheers, > Fraser ACK. -- Endi S. Dewata From edewata at redhat.com Fri Jun 3 00:31:55 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 19:31:55 -0500 Subject: [Pki-devel] [PATCH] 0111 Lightweight CAs: remove NSSDB material when processing deletion In-Reply-To: <20160516040740.GC1323@dhcp-40-8.bne.redhat.com> References: <20160516040740.GC1323@dhcp-40-8.bne.redhat.com> Message-ID: On 5/15/2016 11:07 PM, Fraser Tweedale wrote: > The attached patch makes clones delete lightweight CA keys/certs > from local NSSDB when processing LWCA deletion. > > Ticket: https://fedorahosted.org/pki/ticket/2328 > > Thanks, > Fraser ACK. -- Endi S. Dewata From jmagne at redhat.com Fri Jun 3 00:54:38 2016 From: jmagne at redhat.com (John Magne) Date: Thu, 2 Jun 2016 20:54:38 -0400 (EDT) Subject: [Pki-devel] [PATCH] pki-cfu-0127-Ticket-2271-Part2-TMS-removing-reducing-debug-log-pr.patch In-Reply-To: <5750C6DB.3000901@redhat.com> References: <5750C6DB.3000901@redhat.com> Message-ID: <486812385.11778920.1464915278688.JavaMail.zimbra@redhat.com> Thanks to some tough work here ACK : Took a look at the code and then scanned carefully some test logs and the logs for TPS and TKS are completely streamlined. ----- Original Message ----- > From: "Christina Fu" > To: "pki-devel" > Sent: Thursday, 2 June, 2016 4:52:59 PM > Subject: [Pki-devel] [PATCH] pki-cfu-0127-Ticket-2271-Part2-TMS-removing-reducing-debug-log-pr.patch > > Ticket #2271 Part2:TMS:removing/reducing debug log printout of data > This patch comments out unneeded data in TMS debug logs (TPS&TKS); > It reduces the size of the debug logs by a lot. > Note that for ease of later development debugging, the debug lines > are commented out instead of being removed > > Testing was done in > * formatting > * formatting with key upgrade > * enrollment with server side key generation > * enrollment > * enrollment with key recovery > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Jun 3 01:02:35 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 20:02:35 -0500 Subject: [Pki-devel] [PATCH] 0112 Return 410 Gone if target CA of request has been deleted In-Reply-To: <20160517052020.GH1323@dhcp-40-8.bne.redhat.com> References: <20160517052020.GH1323@dhcp-40-8.bne.redhat.com> Message-ID: <2e0387cb-a557-d144-3834-3413e14551d7@redhat.com> On 5/17/2016 12:20 AM, Fraser Tweedale wrote: > Hi all, > attached patch fixes https://fedorahosted.org/pki/ticket/2332 > > Cheers, > Fraser Assuming an identical CA cannot be created to replace the old one, HTTP 410 Gone is fine. If it's possible, it should be HTTP 404 Not Found. ACK. -- Endi S. Dewata From cfu at redhat.com Fri Jun 3 01:08:51 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 2 Jun 2016 18:08:51 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0127-Ticket-2271-Part2-TMS-removing-reducing-debug-log-pr.patch In-Reply-To: <486812385.11778920.1464915278688.JavaMail.zimbra@redhat.com> References: <5750C6DB.3000901@redhat.com> <486812385.11778920.1464915278688.JavaMail.zimbra@redhat.com> Message-ID: <5750D8A3.8000802@redhat.com> commit 897fd14bfdfa4cd722f95ba60c8dd7a9eaa37219 thanks! Christina On 06/02/2016 05:54 PM, John Magne wrote: > Thanks to some tough work here ACK : > > Took a look at the code and then scanned carefully some test logs and > the logs for TPS and TKS are completely streamlined. > > > > > ----- Original Message ----- >> From: "Christina Fu" >> To: "pki-devel" >> Sent: Thursday, 2 June, 2016 4:52:59 PM >> Subject: [Pki-devel] [PATCH] pki-cfu-0127-Ticket-2271-Part2-TMS-removing-reducing-debug-log-pr.patch >> >> Ticket #2271 Part2:TMS:removing/reducing debug log printout of data >> This patch comments out unneeded data in TMS debug logs (TPS&TKS); >> It reduces the size of the debug logs by a lot. >> Note that for ease of later development debugging, the debug lines >> are commented out instead of being removed >> >> Testing was done in >> * formatting >> * formatting with key upgrade >> * enrollment with server side key generation >> * enrollment >> * enrollment with key recovery >> >> thanks, >> Christina >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Jun 3 03:28:00 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 22:28:00 -0500 Subject: [Pki-devel] [PATCH] 0113..0114 Lightweight CAs: renewal support In-Reply-To: <20160517052624.GI1323@dhcp-40-8.bne.redhat.com> References: <20160517052624.GI1323@dhcp-40-8.bne.redhat.com> Message-ID: <113f9b56-b71c-2471-a16a-f45db60d199e@redhat.com> On 5/17/2016 12:26 AM, Fraser Tweedale wrote: > Attached patches implement LWCA renewal support > (https://fedorahosted.org/pki/ticket/2327). > > It includes REST API > > POST /ca/rest/authorities//renew > > But not implemented in CLI tool yet. If we decide to make it a > first-class CLI feature (cf certmonger, IPA, etc managing the > renewal) then I'll file the ticket and implement it at that time. > > Cheers, > Fraser Some comments: 1. This is related to patch #111 too. Suppose an authority is added/deleted/renewed in one replica while another replica is down, when the second replica is brought back up will it know that it's missing the changes and be able to update the NSSDB accordingly? I'm thinking when the server is started there should be a process to synchronize the NSSDB with the authorities in LDAP. Do we have something like that already, or is this not an issue? 2. The locale object for the RenewalProcessor should be obtained from the client, not from the server. See PKIService.getLocale(). In this case you probably need to pass HttpServletRequest to the renewAuthority(). 3. The HttpServletRequest can be used to call processRenewal() as well. I think #1 can be done separately later. The patches are ACKed assuming #2 and #3 are addressed. -- Endi S. Dewata From edewata at redhat.com Fri Jun 3 03:28:15 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 22:28:15 -0500 Subject: [Pki-devel] [PATCH] 0115 Include serial of revoked cert in CertRequestInfo In-Reply-To: <20160530013150.GC4744@dhcp-40-8.bne.redhat.com> References: <20160530013150.GC4744@dhcp-40-8.bne.redhat.com> Message-ID: <414b079b-5760-545f-1f9d-cd23088b5630@redhat.com> On 5/29/2016 8:31 PM, Fraser Tweedale wrote: > Please review the attached patch, which addresses > https://fedorahosted.org/pki/ticket/1073 > > Cheers, > Fraser ACK. -- Endi S. Dewata From edewata at redhat.com Fri Jun 3 04:45:38 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 23:45:38 -0500 Subject: [Pki-devel] [PATCH] 0117..0119 Retry key retrieval on failure In-Reply-To: <20160601043140.GW4744@dhcp-40-8.bne.redhat.com> References: <20160601043140.GW4744@dhcp-40-8.bne.redhat.com> Message-ID: On 5/31/2016 11:31 PM, Fraser Tweedale wrote: > Hi team, > > The attached patches implement key retrieval retry with backoff > (ticket: https://fedorahosted.org/pki/ticket/2293). > > Thanks, > Fraser ACK. -- Endi S. Dewata From edewata at redhat.com Fri Jun 3 04:45:43 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 2 Jun 2016 23:45:43 -0500 Subject: [Pki-devel] [PATCH] 0120..0121 Remove pki-ipa-retrieve-key script In-Reply-To: <20160601044559.GX4744@dhcp-40-8.bne.redhat.com> References: <20160601044559.GX4744@dhcp-40-8.bne.redhat.com> Message-ID: On 5/31/2016 11:45 PM, Fraser Tweedale wrote: > G'day comrades, > > Please review the attached two patches, which... > > (Patch 0120) > > - provide for passing of configuration (from CS.cfg) to KeyRetriever > implementations > > - generalise IPACustodiaKeyRetriever to ExternalProcessKeyRetriever, > which executes a configured executable rather than a hardcoded one > > (Patch 0121) > > - remove pki-ipa-retrieve-key script; it is being moved to FreeIPA > repo > > Cheers, > Fraser ACK. Separate issue. Instead of returning multiple binary attributes delimited with 0 byte through standard output, it might be better to use JSON file instead. So the command can be defined something like this: features.authority.keyRetrieverConfig.exec=/usr/libexec/pki-ipa-retrieve-key -o {output} The ExternalProcessKeyRetriever will replace the {output} with a temporary file, then later parse the result from that file. -- Endi S. Dewata From mharmsen at redhat.com Fri Jun 3 05:35:12 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 2 Jun 2016 23:35:12 -0600 Subject: [Pki-devel] [PATCH] Certificate Nickname Improvement Message-ID: <57511710.1070802@redhat.com> Please review the attached patch which addresses the following ticket: * PKI TRAC Ticket #1432 - Certificate nickname improvement This was tested by successfully: * creating a shared PKI instance containing a CA, KRA, OCSP, TKS, and TPS, * creating a separated CA, * creating a separated KRA, * creating a separated OCSP, * creating a separated TKS, * creating a separated TPS, and * installing a FreeIPA instance Detailed contents of the nicknames as they appear in the NSS security databases of both the shared PKI instance as well as each of the separated PKI instances is detailed in the above ticket. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20160602-Certificate-nickname-improvement.patch Type: text/x-patch Size: 39848 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jun 3 05:45:06 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Jun 2016 15:45:06 +1000 Subject: [Pki-devel] [PATCH] 0110 Lightweight CAs: remove redundant deletePrivateKey invocation In-Reply-To: References: <20160516032609.GB1323@dhcp-40-8.bne.redhat.com> Message-ID: <20160603054506.GO4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 07:10:49PM -0500, Endi Sukma Dewata wrote: > On 5/15/2016 10:26 PM, Fraser Tweedale wrote: > > Hi team, > > > > The attached patch fixes https://fedorahosted.org/pki/ticket/1640. > > > > Cheers, > > Fraser > > ACK. > Thanks; pushed to master (c685a4195cdde16e875478b0f4554e688762f927) From ftweedal at redhat.com Fri Jun 3 05:45:23 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Jun 2016 15:45:23 +1000 Subject: [Pki-devel] [PATCH] 0111 Lightweight CAs: remove NSSDB material when processing deletion In-Reply-To: References: <20160516040740.GC1323@dhcp-40-8.bne.redhat.com> Message-ID: <20160603054523.GP4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 07:31:55PM -0500, Endi Sukma Dewata wrote: > On 5/15/2016 11:07 PM, Fraser Tweedale wrote: > > The attached patch makes clones delete lightweight CA keys/certs > > from local NSSDB when processing LWCA deletion. > > > > Ticket: https://fedorahosted.org/pki/ticket/2328 > > > > Thanks, > > Fraser > > ACK. > Thanks; pushed to master (64b62b1ce44b9baf40b5bcd913c89a1a513803ae) From ftweedal at redhat.com Fri Jun 3 05:52:52 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Jun 2016 15:52:52 +1000 Subject: [Pki-devel] [PATCH] 0112 Return 410 Gone if target CA of request has been deleted In-Reply-To: <2e0387cb-a557-d144-3834-3413e14551d7@redhat.com> References: <20160517052020.GH1323@dhcp-40-8.bne.redhat.com> <2e0387cb-a557-d144-3834-3413e14551d7@redhat.com> Message-ID: <20160603055252.GQ4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 08:02:35PM -0500, Endi Sukma Dewata wrote: > On 5/17/2016 12:20 AM, Fraser Tweedale wrote: > > Hi all, > > attached patch fixes https://fedorahosted.org/pki/ticket/2332 > > > > Cheers, > > Fraser > > Assuming an identical CA cannot be created to replace the old one, HTTP 410 > Gone is fine. If it's possible, it should be HTTP 404 Not Found. ACK. > Authority IDs are random UUIDs, so I think we can safely say that Gone means Gone :) Thanks for reviewing! Pushed to master (443ad5e35e106f84b5439ee7d2861ccd5d6245f3) From ftweedal at redhat.com Fri Jun 3 05:55:20 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Jun 2016 15:55:20 +1000 Subject: [Pki-devel] [PATCH] 0115 Include serial of revoked cert in CertRequestInfo In-Reply-To: <414b079b-5760-545f-1f9d-cd23088b5630@redhat.com> References: <20160530013150.GC4744@dhcp-40-8.bne.redhat.com> <414b079b-5760-545f-1f9d-cd23088b5630@redhat.com> Message-ID: <20160603055520.GR4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 10:28:15PM -0500, Endi Sukma Dewata wrote: > On 5/29/2016 8:31 PM, Fraser Tweedale wrote: > > Please review the attached patch, which addresses > > https://fedorahosted.org/pki/ticket/1073 > > > > Cheers, > > Fraser > > ACK. > Thanks; pushed to master (9bcc0bba57003a26ee0488def88a57ca883d9134) From ftweedal at redhat.com Fri Jun 3 06:00:16 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Jun 2016 16:00:16 +1000 Subject: [Pki-devel] [PATCH] 0117..0119 Retry key retrieval on failure In-Reply-To: References: <20160601043140.GW4744@dhcp-40-8.bne.redhat.com> Message-ID: <20160603060016.GS4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 11:45:38PM -0500, Endi Sukma Dewata wrote: > On 5/31/2016 11:31 PM, Fraser Tweedale wrote: > > Hi team, > > > > The attached patches implement key retrieval retry with backoff > > (ticket: https://fedorahosted.org/pki/ticket/2293). > > > > Thanks, > > Fraser > > ACK. > Thanks Endi; pushed to master: f78af863edb020db763ce7920b3b0a6ea61d8e5e Retry failed key retrieval with backoff 9062e0265e7cadfa05f64a7c5c0a718594283d06 Don't update obsolete CertificateAuthority after key retrieval b1bafc4935c088fe98373a7988f5e0518b950226 Limit key retrieval to a single thread per CA From ftweedal at redhat.com Fri Jun 3 06:23:03 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Jun 2016 16:23:03 +1000 Subject: [Pki-devel] [PATCH] Certificate Nickname Improvement In-Reply-To: <57511710.1070802@redhat.com> References: <57511710.1070802@redhat.com> Message-ID: <20160603062302.GT4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 11:35:12PM -0600, Matthew Harmsen wrote: > Please review the attached patch which addresses the following ticket: > > * PKI TRAC Ticket #1432 - Certificate nickname improvement > > > This was tested by successfully: > > * creating a shared PKI instance containing a CA, KRA, OCSP, TKS, and TPS, > * creating a separated CA, > * creating a separated KRA, > * creating a separated OCSP, > * creating a separated TKS, > * creating a separated TPS, and > * installing a FreeIPA instance > > Detailed contents of the nicknames as they appear in the NSS security > databases of both the shared PKI instance as well as each of the separated > PKI instances is detailed in the above ticket. > Not a NACK, but please HOLD this patch until I can thoroughly review it and determine its impact on IPA. A lot of the nicknames are currently hardcoded in IPA. Installation may work but I can all but guarantee this will break replica installation and automatic renewal. I (or someone) will need time to work out the impact on IPA and proactively ensure that IPA will continue to work after this change. (That probably won't happen in time for 10.3.2 release, sorry!) Thanks, Fraser From ftweedal at redhat.com Fri Jun 3 06:32:54 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 3 Jun 2016 16:32:54 +1000 Subject: [Pki-devel] [PATCH] 0120..0121 Remove pki-ipa-retrieve-key script In-Reply-To: References: <20160601044559.GX4744@dhcp-40-8.bne.redhat.com> Message-ID: <20160603063254.GU4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 11:45:43PM -0500, Endi Sukma Dewata wrote: > On 5/31/2016 11:45 PM, Fraser Tweedale wrote: > > G'day comrades, > > > > Please review the attached two patches, which... > > > > (Patch 0120) > > > > - provide for passing of configuration (from CS.cfg) to KeyRetriever > > implementations > > > > - generalise IPACustodiaKeyRetriever to ExternalProcessKeyRetriever, > > which executes a configured executable rather than a hardcoded one > > > > (Patch 0121) > > > > - remove pki-ipa-retrieve-key script; it is being moved to FreeIPA > > repo > > > > Cheers, > > Fraser > > ACK. > > Separate issue. Instead of returning multiple binary attributes delimited > with 0 byte through standard output, it might be better to use JSON file > instead. So the command can be defined something like this: > > features.authority.keyRetrieverConfig.exec=/usr/libexec/pki-ipa-retrieve-key > -o {output} > > The ExternalProcessKeyRetriever will replace the {output} with a temporary > file, then later parse the result from that file. > Thanks Endi; pushed to master: 419ca3000142c60f176aabc68a2c5c3a1a3c1ea9 Lightweight CAs: remove pki-ipa-retrieve-key script f11e0b372e3a0736050dd9e2858fce3178171ee6 Lightweight CAs: generalise subprocess-based key retrieval I agree with the JSON enhancement, but not with using a temporary file; we can just send the JSON through stdout. I filed ticket: https://fedorahosted.org/pki/ticket/2351 Cheers, Fraser From alee at redhat.com Fri Jun 3 12:57:55 2016 From: alee at redhat.com (Ade Lee) Date: Fri, 03 Jun 2016 08:57:55 -0400 Subject: [Pki-devel] [PATCH] 315-319 KRA realm related patches In-Reply-To: <7a425667-5a56-daea-2909-38c6b6774f32@redhat.com> References: <1464875400.7327.2.camel@redhat.com> <1464875472.7327.4.camel@redhat.com> <7a425667-5a56-daea-2909-38c6b6774f32@redhat.com> Message-ID: <1464958675.25179.1.camel@redhat.com> Made fix 1 below and pushed 315-318 to master. After much discussion with Endi, figured out how best to refactor 319. Will resubmit as 320. Thanks, Ade On Thu, 2016-06-02 at 14:10 -0500, Endi Sukma Dewata wrote: > On 6/2/2016 8:51 AM, Ade Lee wrote: > > And now with the patches .. > > > > On Thu, 2016-06-02 at 09:50 -0400, Ade Lee wrote: > > > Patch descriptions (in reverse order). > > > > > > The final patch will need some discussion. Please review, > > > > > > Ade > > Some comments: > > 1. In SrchKey and SrchKeyForRecovery the check probably should have > been > like this (no closing paren): > > if (filter.contains("(realm=")) { > > 2. If a realm is specified, I suppose it won't match any of the VLV > indexes. Do the queries still work correctly without a matching VLV? > > 3. Could you document how to run the upgrade command in this page? > http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x > > Note that there are still some manual upgrade procedures that also > need > to be executed as documented in that page. > > 4. In PKISubsystem.open_database() can we use bind_dn and > bind_password > parameter names instead of user and password (it's a DN not a user > ID)? > Also in DBUpgrade should we use -D, -w, and -Z for consistency with > DS > tools? > > 5. The gnu_getopt() is called with "server_id=". I think it should be > "server-id=". But since it actually contains the DS instance name > maybe > we should use "ds-instance=" instead? > > 6. In the DBUpgrade.modify_kra_vlv() the os.unlink(ldif_file) > probably > should be moved into the finally clause above it to ensure the > temporary > file is deleted in all cases. Alternatively the code could be written > like this: > > with NamedTemporaryFile() as ldif_file: > # do everything with the ldif_file here > > 7. In DBUpgrade.modify_schema() why not use subsystem.open_database() > instead of ldapmodify? That will ensure it uses the same mechanism to > connect to the LDAP server. > > 8. Also the DBUpgrade.modify_schema() is ignoring all schema update > failures. I think we can only ignore the case where the new schema is > already added. In other cases the upgrade should fail since the > subsequent upgrades may depend on it. > > 9. I think DBUpgrade.create_realm_index() should only execute if > there's > a KRA subsystem in the instance. The code right now creates the index > in > the first subsystem's database which may not be a KRA. > > subsystem = instance.subsystems[0] > > 10. The DBUpgrade uses db2index.pl to rebuild the indexes which means > the LDAP server must run locally. To support remote LDAP server I > think > we need to use reindex task. We have indextasks.ldif and > vlvtasks.ldif > that can be used for this. See also: > http://pki.fedoraproject.org/wiki/DS_Database_Indexes > > 11. The DBUpgrade should not ignore reindex failures since subsequent > upgrades may depend on it. > > 12. There's a typo in the last patch's commit description. > From alee at redhat.com Fri Jun 3 12:59:23 2016 From: alee at redhat.com (Ade Lee) Date: Fri, 03 Jun 2016 08:59:23 -0400 Subject: [Pki-devel] [PATCH] 320 - pki-server db changes Message-ID: <1464958763.25179.3.camel@redhat.com> commit 9450b5f7695cc827cced6e86281694daa1e5c2c8 Author: Ade Lee Date: Thu Jun 2 09:41:35 2016 -0400 Add commands to db-server to help with DB related changes Added pki-server kra-db-vlv-add, kra-db-vlv-del, kra-db-vlv-reindex Added pki-server db-schema-upgrade If the admin has the directory manager (or equivalent) simple creds, then they can enter them as parameters and perform the operations. Otherwise, they can specify --generate-ldif to generate LDIF files containing the changes that need to be implemented, and implement them using GSSAPI or otherwise. Tickets 2320, 2319 Please review, Thanks, Ade From alee at redhat.com Fri Jun 3 13:00:11 2016 From: alee at redhat.com (Ade Lee) Date: Fri, 03 Jun 2016 09:00:11 -0400 Subject: [Pki-devel] [PATCH] 320 - pki-server db changes In-Reply-To: <1464958763.25179.3.camel@redhat.com> References: <1464958763.25179.3.camel@redhat.com> Message-ID: <1464958811.25179.4.camel@redhat.com> With patch this time: On Fri, 2016-06-03 at 08:59 -0400, Ade Lee wrote: > commit 9450b5f7695cc827cced6e86281694daa1e5c2c8 > Author: Ade Lee > Date: Thu Jun 2 09:41:35 2016 -0400 > > Add commands to db-server to help with DB related changes > > Added pki-server kra-db-vlv-add, kra-db-vlv-del, kra-db-vlv > -reindex > Added pki-server db-schema-upgrade > > If the admin has the directory manager (or equivalent) simple > creds, > then they can enter them as parameters and perform the > operations. > > Otherwise, they can specify --generate-ldif to generate LDIF > files > containing the changes that need to be implemented, and implement > them using GSSAPI or otherwise. > > Tickets 2320, 2319 > > Please review, > Thanks, > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0320-Add-commands-to-db-server-to-help-with-DB-related-ch.patch Type: text/x-patch Size: 19111 bytes Desc: not available URL: From alee at redhat.com Fri Jun 3 14:01:40 2016 From: alee at redhat.com (Ade Lee) Date: Fri, 03 Jun 2016 10:01:40 -0400 Subject: [Pki-devel] [PATCH] 321 - fix for ticket 1717 Message-ID: <1464962500.25179.6.camel@redhat.com> commit 2d92a69d7f211eabc1c59714036ef1aba4fc1fd4 Author: Ade Lee Date: Thu Jun 2 12:20:20 2016 -0400 Add option to modify ajp_host to pkispawn This allows IPA to handle the case of a pure ipv6 environment in which the ipv4 loopback interface is not available. Ticket 1717 -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0321-Add-option-to-modify-ajp_host-to-pkispawn.patch Type: text/x-patch Size: 5103 bytes Desc: not available URL: From cfu at redhat.com Fri Jun 3 17:22:07 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 3 Jun 2016 10:22:07 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch Message-ID: <5751BCBF.8010409@redhat.com> https://fedorahosted.org/pki/ticket/2352 Ticket #2352 [TMS] missing netkeyKeyRecovery requests option in KRA agent for "List Request" This patch allows KRA agent to list netkeyKeyRecovery requests thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch Type: text/x-patch Size: 2575 bytes Desc: not available URL: From jmagne at redhat.com Fri Jun 3 17:42:31 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 3 Jun 2016 13:42:31 -0400 (EDT) Subject: [Pki-devel] [PATCH] pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch In-Reply-To: <5751BCBF.8010409@redhat.com> References: <5751BCBF.8010409@redhat.com> Message-ID: <1900638055.12206462.1464975751093.JavaMail.zimbra@redhat.com> ACK Does the job with little fuss. One thing I would push for is to leave the original labels for standard requests the way they were and NOT call them "Non Token ...." requests. This we the old behavior remains and the user can explore the new options provided for TMS related requests if they so choose. ----- Original Message ----- > From: "Christina Fu" > To: "pki-devel" > Sent: Friday, June 3, 2016 10:22:07 AM > Subject: [Pki-devel] [PATCH] pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch > > https://fedorahosted.org/pki/ticket/2352 > Ticket #2352 [TMS] missing netkeyKeyRecovery requests option in KRA > agent for "List Request" > This patch allows KRA agent to list netkeyKeyRecovery requests > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Fri Jun 3 18:28:29 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 3 Jun 2016 11:28:29 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch In-Reply-To: <1900638055.12206462.1464975751093.JavaMail.zimbra@redhat.com> References: <5751BCBF.8010409@redhat.com> <1900638055.12206462.1464975751093.JavaMail.zimbra@redhat.com> Message-ID: <5751CC4D.2070409@redhat.com> The original "Show archival requests" and "Show recovery requests" are actually quite misleading, as they do NOT show any archival or recovery requests for TMS. However, for the lack of a better idea, I'll leave them as is. commit 1c5458150d583481415e2bde4e68d8ab7bbf56d9 thanks, Christina On 06/03/2016 10:42 AM, John Magne wrote: > ACK > > Does the job with little fuss. > > One thing I would push for is to leave the original labels for standard requests > the way they were and NOT call them "Non Token ...." requests. > > This we the old behavior remains and the user can explore the new options provided > for TMS related requests if they so choose. > > > > > ----- Original Message ----- >> From: "Christina Fu" >> To: "pki-devel" >> Sent: Friday, June 3, 2016 10:22:07 AM >> Subject: [Pki-devel] [PATCH] pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch >> >> https://fedorahosted.org/pki/ticket/2352 >> Ticket #2352 [TMS] missing netkeyKeyRecovery requests option in KRA >> agent for "List Request" >> This patch allows KRA agent to list netkeyKeyRecovery requests >> >> thanks, >> Christina >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Jun 3 19:44:31 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 3 Jun 2016 14:44:31 -0500 Subject: [Pki-devel] [PATCH] 761 Fixed truncated token activity message in TPS UI. Message-ID: <9e0665bb-520f-5d9b-fc9e-f182dbdf2701@redhat.com> The TPS UI has been modified to display the token activity message in a textarea to avoid truncation. The UI framework class has been modified to handle textarea. The CSS has been modified to align the field label with the top of textarea. https://fedorahosted.org/pki/ticket/2299 Pushed to master under one-liner/trivial rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0761-Fixed-truncated-token-activity-message-in-TPS-UI.patch Type: text/x-patch Size: 3160 bytes Desc: not available URL: From cfu at redhat.com Fri Jun 3 21:46:28 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 3 Jun 2016 14:46:28 -0700 Subject: [Pki-devel] [pki-devel][PATCH] 0069-Show-KeyOwner-info-when-viewing-recovery-requests.patch In-Reply-To: <807574163.11035031.1464819233747.JavaMail.zimbra@redhat.com> References: <807574163.11035031.1464819233747.JavaMail.zimbra@redhat.com> Message-ID: <5751FAB4.9020309@redhat.com> while the patch works, I think the original code logic is somehow flawed in a way that it uses the "profile" attribute to determine whether the request was non-TMS archival requests, and if null it treats it as TMS. It would make better sense if we add a separate case instead of lumping the handling of recovery requests inside where the TMS handling is at. thanks, Christina On 06/01/2016 03:13 PM, John Magne wrote: > Show KeyOwner info when viewing recovery requests. > > This simple fix will grab the subject info out of the cert > associated with either pending or complete recovery requests being > viewed in the KRA UI. > > For example: > > KeyOwner: UID=jmagne, O=Token Key User > > Will be displayed. > Have seen this display for both pending and completed recovery requests. > > This simple fix should be good enough for this round, despite the bug > asking about agent info and such. Those enhancements for later. > > Ticket : Ticket #1512 : Key owner info missing from the Search results of Recovery request > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Fri Jun 3 22:23:30 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 3 Jun 2016 18:23:30 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0069-Show-KeyOwner-info-when-viewing-recovery-requests.patch In-Reply-To: <5751FAB4.9020309@redhat.com> References: <807574163.11035031.1464819233747.JavaMail.zimbra@redhat.com> <5751FAB4.9020309@redhat.com> Message-ID: <1682702359.12249261.1464992610134.JavaMail.zimbra@redhat.com> Pushed to master based on cfu's verbal conditional ACK for this (after I modded it the way she requested) Tested to work. commit 3cd58a98022141da2af4bf0bad29ab1dbdc86fbe Author: Jack Magne Date: Wed Jun 1 15:05:20 2016 -0700 Closing ticket #1512 ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Friday, June 3, 2016 2:46:28 PM > Subject: Re: [Pki-devel] [pki-devel][PATCH] 0069-Show-KeyOwner-info-when-viewing-recovery-requests.patch > > while the patch works, I think the original code logic is somehow flawed in a > way that it uses the "profile" attribute to determine whether the request > was non-TMS archival requests, and if null it treats it as TMS. It would > make better sense if we add a separate case instead of lumping the handling > of recovery requests inside where the TMS handling is at. > > thanks, > Christina > > On 06/01/2016 03:13 PM, John Magne wrote: > > > > Show KeyOwner info when viewing recovery requests. > > This simple fix will grab the subject info out of the cert > associated with either pending or complete recovery requests being > viewed in the KRA UI. > > For example: > > KeyOwner: UID=jmagne, O=Token Key User > > Will be displayed. > Have seen this display for both pending and completed recovery requests. > > This simple fix should be good enough for this round, despite the bug > asking about agent info and such. Those enhancements for later. > > Ticket : Ticket #1512 : Key owner info missing from the Search results of > Recovery request > > > _______________________________________________ > Pki-devel mailing list Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Jun 3 23:49:56 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 3 Jun 2016 18:49:56 -0500 Subject: [Pki-devel] [PATCH] 762 Removed selftest interface from TPS UI. Message-ID: <5bceab4b-5a4f-a713-44b0-c91850be0e43@redhat.com> The selftest interface has been removed from TPS UI to avoid confusion due to its limited usefulness. https://fedorahosted.org/pki/ticket/2344 Pushed to master under one-liner/trivial rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0762-Removed-selftest-interface-from-TPS-UI.patch Type: text/x-patch Size: 2003 bytes Desc: not available URL: From cfu at redhat.com Sat Jun 4 00:29:58 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 3 Jun 2016 17:29:58 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0131-Ticket-2335-Missing-activity-logs-when-formatting-en.patch Message-ID: <57522106.9080601@redhat.com> https://fedorahosted.org/pki/ticket/2335 Ticket #2335 Missing activity logs when formatting/enrolling unknown token This patch adds activity logs for adding unknown token during format or enrollment thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0131-Ticket-2335-Missing-activity-logs-when-formatting-en.patch Type: text/x-patch Size: 9283 bytes Desc: not available URL: From ftweedal at redhat.com Sat Jun 4 11:00:14 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 4 Jun 2016 21:00:14 +1000 Subject: [Pki-devel] [PATCH] 0122 Modify ExternalProcessKeyRetriever to read JSON Message-ID: <20160604110014.GA4744@dhcp-40-8.bne.redhat.com> Hi Endi et al, Attached patch changes ExternalProcessKeyRetriever to read JSON data (https://fedorahosted.org/pki/ticket/2351). Would be nice to get this into 10.2.2 because it will simplify IPA custodia retrieval helper. I am using Jackson for JSON parsing. This is already an implicit dependency, but should I also add it spec file as explicit dependency? Cheers, Fraser -------------- next part -------------- From 7183cece34b766b5e1db6837291151b4d58aa9c9 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Sat, 4 Jun 2016 20:49:38 +1000 Subject: [PATCH] Modify ExternalProcessKeyRetriever to read JSON The ExternalProcessKeyRetriever currently uses a hackish format where the certificate and PKIArchiveOptions data are separated by a null byte. Update the code to expect JSON instead. No backwards compatibility is provided because at time of writing the ExternalProcessKeyRetriever is only used in a FreeIPA feature still under development. Fixes: https://fedorahosted.org/pki/ticket/2351 --- base/ca/src/CMakeLists.txt | 15 +++++++++ .../netscape/ca/ExternalProcessKeyRetriever.java | 37 +++++++++++++--------- 2 files changed, 37 insertions(+), 15 deletions(-) diff --git a/base/ca/src/CMakeLists.txt b/base/ca/src/CMakeLists.txt index 1817dacfbacaeb2635db2550e32ff62c26d628ef..2a43c8dbb4f88c22df244bb752ea963b2f0d646c 100644 --- a/base/ca/src/CMakeLists.txt +++ b/base/ca/src/CMakeLists.txt @@ -38,6 +38,20 @@ find_file(COMMONS_LANG_JAR /usr/share/java ) +find_file(JACKSON_CORE_JAR + NAMES + jackson-core-asl.jar + PATHS + /usr/share/java/jackson +) + +find_file(JACKSON_MAPPER_JAR + NAMES + jackson-mapper-asl.jar + PATHS + /usr/share/java/jackson +) + find_file(JAXRS_API_JAR NAMES jaxrs-api.jar @@ -81,6 +95,7 @@ javac(pki-ca-classes org/dogtagpki/server/ca/*.java CLASSPATH ${COMMONS_CODEC_JAR} ${COMMONS_IO_JAR} ${COMMONS_LANG_JAR} + ${JACKSON_CORE_JAR} ${JACKSON_MAPPER_JAR} ${JSS_JAR} ${SYMKEY_JAR} ${LDAPJDK_JAR} ${SERVLET_JAR} ${TOMCAT_CATALINA_JAR} diff --git a/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java b/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java index 6aee9716e1e5953018ed4c3f3316c9b7d4c88a45..a1b77485284d699bbb524bfc64b3c348663c4c1e 100644 --- a/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java +++ b/base/ca/src/com/netscape/ca/ExternalProcessKeyRetriever.java @@ -18,6 +18,8 @@ package com.netscape.ca; +import java.io.IOException; +import java.io.InputStream; import java.lang.Process; import java.lang.ProcessBuilder; import java.util.Collection; @@ -26,6 +28,9 @@ import java.util.Stack; import org.apache.commons.io.IOUtils; import org.apache.commons.lang.ArrayUtils; +import org.codehaus.jackson.map.ObjectMapper; +import org.codehaus.jackson.JsonNode; + import com.netscape.certsrv.apps.CMS; import com.netscape.certsrv.base.EBaseException; import com.netscape.certsrv.base.EPropertyNotFound; @@ -65,21 +70,7 @@ public class ExternalProcessKeyRetriever implements KeyRetriever { int exitValue = p.waitFor(); if (exitValue != 0) continue; - - /* Read a PEM-encoded certificate and a base64-encoded - * PKIArchiveOptions containing the wrapped private key, - * separated by a null byte. - */ - byte[] output = IOUtils.toByteArray(p.getInputStream()); - int splitIndex = ArrayUtils.indexOf(output, (byte) 0); - if (splitIndex == ArrayUtils.INDEX_NOT_FOUND) { - CMS.debug("Invalid output: null byte not found"); - continue; - } - return new Result( - ArrayUtils.subarray(output, 0, splitIndex), - ArrayUtils.subarray(output, splitIndex + 1, output.length) - ); + return parseResult(p.getInputStream()); } catch (Throwable e) { CMS.debug("Caught exception while executing command: " + e); } finally { @@ -89,4 +80,20 @@ public class ExternalProcessKeyRetriever implements KeyRetriever { CMS.debug("Failed to retrieve key from any host."); return null; } + + /* Read a PEM-encoded certificate and a base64-encoded + * PKIArchiveOptions containing the wrapped private key. + * Data is expected to be a JSON object with keys "certificate" + * and "wrapped_key". + */ + private Result parseResult(InputStream in) throws IOException { + JsonNode root = (new ObjectMapper()).readTree(in); + String cert = root.path("certificate").getTextValue(); + byte[] pao = root.path("wrapped_key").getBinaryValue(); + if (cert == null) + throw new RuntimeException("missing \"certificate\" field"); + if (pao == null) + throw new RuntimeException("missing \"wrapped_key\" field"); + return new Result(cert.getBytes(), pao); + } } -- 2.5.5 From ftweedal at redhat.com Sat Jun 4 12:43:48 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 4 Jun 2016 22:43:48 +1000 Subject: [Pki-devel] [PATCH] 0113..0114 Lightweight CAs: renewal support In-Reply-To: <113f9b56-b71c-2471-a16a-f45db60d199e@redhat.com> References: <20160517052624.GI1323@dhcp-40-8.bne.redhat.com> <113f9b56-b71c-2471-a16a-f45db60d199e@redhat.com> Message-ID: <20160604124348.GC4744@dhcp-40-8.bne.redhat.com> On Thu, Jun 02, 2016 at 10:28:00PM -0500, Endi Sukma Dewata wrote: > On 5/17/2016 12:26 AM, Fraser Tweedale wrote: > > Attached patches implement LWCA renewal support > > (https://fedorahosted.org/pki/ticket/2327). > > > > It includes REST API > > > > POST /ca/rest/authorities//renew > > > > But not implemented in CLI tool yet. If we decide to make it a > > first-class CLI feature (cf certmonger, IPA, etc managing the > > renewal) then I'll file the ticket and implement it at that time. > > > > Cheers, > > Fraser > > Some comments: > > 1. This is related to patch #111 too. Suppose an authority is > added/deleted/renewed in one replica while another replica is down, when the > second replica is brought back up will it know that it's missing the changes > and be able to update the NSSDB accordingly? > > I'm thinking when the server is started there should be a process to > synchronize the NSSDB with the authorities in LDAP. Do we have something > like that already, or is this not an issue? > Nice pickup - this will be an issue (I agree it can be addressed later; I'll create a ticket). > 2. The locale object for the RenewalProcessor should be obtained from the > client, not from the server. See PKIService.getLocale(). In this case you > probably need to pass HttpServletRequest to the renewAuthority(). > > 3. The HttpServletRequest can be used to call processRenewal() as well. > > I think #1 can be done separately later. The patches are ACKed assuming #2 > and #3 are addressed. > Updated patch attached. I pass in the HttpServletRequest to processRenewal() and use the authToken from the principal if available (I also removed the method signature with the IAuthToken argument, which was added in the first patch). If you're happy with the updated patch and I'm not around, would you kindly merge it on my behalf? Thanks for your many reviews this week, Endi. Fraser From ftweedal at redhat.com Sat Jun 4 12:46:17 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 4 Jun 2016 22:46:17 +1000 Subject: [Pki-devel] [PATCH] 0113..0114 Lightweight CAs: renewal support In-Reply-To: <20160604124348.GC4744@dhcp-40-8.bne.redhat.com> References: <20160517052624.GI1323@dhcp-40-8.bne.redhat.com> <113f9b56-b71c-2471-a16a-f45db60d199e@redhat.com> <20160604124348.GC4744@dhcp-40-8.bne.redhat.com> Message-ID: <20160604124617.GD4744@dhcp-40-8.bne.redhat.com> On Sat, Jun 04, 2016 at 10:43:48PM +1000, Fraser Tweedale wrote: > On Thu, Jun 02, 2016 at 10:28:00PM -0500, Endi Sukma Dewata wrote: > > On 5/17/2016 12:26 AM, Fraser Tweedale wrote: > > > Attached patches implement LWCA renewal support > > > (https://fedorahosted.org/pki/ticket/2327). > > > > > > It includes REST API > > > > > > POST /ca/rest/authorities//renew > > > > > > But not implemented in CLI tool yet. If we decide to make it a > > > first-class CLI feature (cf certmonger, IPA, etc managing the > > > renewal) then I'll file the ticket and implement it at that time. > > > > > > Cheers, > > > Fraser > > > > Some comments: > > > > 1. This is related to patch #111 too. Suppose an authority is > > added/deleted/renewed in one replica while another replica is down, when the > > second replica is brought back up will it know that it's missing the changes > > and be able to update the NSSDB accordingly? > > > > I'm thinking when the server is started there should be a process to > > synchronize the NSSDB with the authorities in LDAP. Do we have something > > like that already, or is this not an issue? > > > Nice pickup - this will be an issue (I agree it can be addressed > later; I'll create a ticket). > > > 2. The locale object for the RenewalProcessor should be obtained from the > > client, not from the server. See PKIService.getLocale(). In this case you > > probably need to pass HttpServletRequest to the renewAuthority(). > > > > 3. The HttpServletRequest can be used to call processRenewal() as well. > > > > I think #1 can be done separately later. The patches are ACKed assuming #2 > > and #3 are addressed. > > > Updated patch attached. I pass in the HttpServletRequest to > processRenewal() and use the authToken from the principal if > available (I also removed the method signature with the IAuthToken > argument, which was added in the first patch). > > If you're happy with the updated patch and I'm not around, would you > kindly merge it on my behalf? > > Thanks for your many reviews this week, Endi. > Fraser Now with patches! -------------- next part -------------- From 7e59d3edfa9ae1e2888e5742618094e32ea9fed9 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 17 May 2016 12:44:03 +1000 Subject: [PATCH 113/114] Lightweight CAs: renew certs with same issuer When renewing a certificate, propagate the Authority ID from the original request to the new request, to ensure that the new certificate is issued by the same issuer as the original. Part of: https://fedorahosted.org/pki/ticket/2327 --- .../cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java b/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java index b22cc1ce4c28d89bc5380d1ab27d90775245abd5..8efa9162afd37cac8f6ba6dedd056ae36be5ce0e 100644 --- a/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java +++ b/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java @@ -214,6 +214,9 @@ public class RenewalProcessor extends CertProcessor { String profileId = origReq.getExtDataInString("profileId"); CMS.debug("RenewalSubmitter: renewal original profileId=" + profileId); + String aidString = origReq.getExtDataInString( + IEnrollProfile.REQUEST_AUTHORITY_ID); + Integer origSeqNum = origReq.getExtDataInInteger(IEnrollProfile.REQUEST_SEQ_NUM); IProfile profile = ps.getProfile(profileId); if (profile == null) { @@ -226,6 +229,10 @@ public class RenewalProcessor extends CertProcessor { } IProfileContext ctx = profile.createContext(); + + if (aidString != null) + ctx.set(IEnrollProfile.REQUEST_AUTHORITY_ID, aidString); + IProfileAuthenticator authenticator = renewProfile.getAuthenticator(); IProfileAuthenticator origAuthenticator = profile.getAuthenticator(); -- 2.5.5 -------------- next part -------------- From 722a682fc4675a2f5c6cca0ddec58db47120a991 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 13 May 2016 09:00:44 +1000 Subject: [PATCH 114/114] Lightweight CAs: add method to renew certificate Add the CertificateAuthority.renewAuthority() method that creates and processes a renewal request for the lightweight CA's signing cert. The new certificate replaces the old certificate in the NSSDB and the serial number is stored in the 'authoritySerial' attribute. Clones observe when the 'authoritySerial' attribute has changed and update the certificate in their NSSDB, too. The renewal behaviour is available in the REST API as a POST to /ca/rest/authorities//renew. Fixes: https://fedorahosted.org/pki/ticket/2327 --- .../src/com/netscape/ca/CertificateAuthority.java | 120 ++++++++++++++++++++- .../dogtagpki/server/ca/rest/AuthorityService.java | 31 ++++++ .../certsrv/authority/AuthorityResource.java | 7 ++ .../netscape/certsrv/ca/ICertificateAuthority.java | 6 ++ .../cms/servlet/cert/RenewalProcessor.java | 9 +- 5 files changed, 168 insertions(+), 5 deletions(-) diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java index 93c5a9fb40a4b1e8f43080f31a04dcfd34f2470c..c9de9f9a58ce91a56043e21d47cd63020b20c085 100644 --- a/base/ca/src/com/netscape/ca/CertificateAuthority.java +++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java @@ -94,6 +94,7 @@ import com.netscape.certsrv.ca.ICertificateAuthority; import com.netscape.certsrv.ca.IssuerUnavailableException; import com.netscape.certsrv.cert.CertEnrollmentRequest; import com.netscape.certsrv.dbs.IDBSubsystem; +import com.netscape.certsrv.dbs.certdb.CertId; import com.netscape.certsrv.dbs.certdb.ICertRecord; import com.netscape.certsrv.dbs.certdb.ICertificateRepository; import com.netscape.certsrv.dbs.crldb.ICRLRepository; @@ -121,6 +122,7 @@ import com.netscape.certsrv.security.ISigningUnit; import com.netscape.certsrv.util.IStatsSubsystem; import com.netscape.cms.servlet.cert.CertEnrollmentRequestFactory; import com.netscape.cms.servlet.cert.EnrollmentProcessor; +import com.netscape.cms.servlet.cert.RenewalProcessor; import com.netscape.cms.servlet.processors.CAProcessor; import com.netscape.cmscore.base.ArgBlock; import com.netscape.cmscore.dbs.CRLRepository; @@ -210,6 +212,7 @@ public class CertificateAuthority protected CertificateAuthority hostCA = null; protected AuthorityID authorityID = null; protected AuthorityID authorityParentID = null; + protected BigInteger authoritySerial = null; protected String authorityDescription = null; protected Collection authorityKeyHosts = null; protected boolean authorityEnabled = true; @@ -346,6 +349,7 @@ public class CertificateAuthority X500Name dn, AuthorityID aid, AuthorityID parentAID, + BigInteger serial, String signingKeyNickname, Collection authorityKeyHosts, String authorityDescription, @@ -360,6 +364,7 @@ public class CertificateAuthority this.authorityID = aid; this.authorityParentID = parentAID; + this.authoritySerial = serial; this.authorityDescription = authorityDescription; this.authorityEnabled = authorityEnabled; mNickname = signingKeyNickname; @@ -526,6 +531,8 @@ public class CertificateAuthority } } + checkForNewerCert(); + mUseNonces = mConfig.getBoolean("enableNonces", true); mMaxNonces = mConfig.getInteger("maxNumberOfNonces", 100); @@ -604,6 +611,49 @@ public class CertificateAuthority } } + private void checkForNewerCert() throws EBaseException { + if (authoritySerial == null) + return; + if (authoritySerial.equals(mCaCert.getSerialNumber())) + return; + + // The authoritySerial recorded in LDAP differs from the + // certificate in NSSDB. Import the newer cert. + // + // Note that the new serial number need not be greater, + // e.g. if random serial numbers are enabled. + // + CMS.debug( + "Updating certificate in NSSDB; new serial number: " + + authoritySerial); + try { + X509Certificate oldCert = mCaX509Cert; + CryptoManager manager = CryptoManager.getInstance(); + + // add new cert + X509CertImpl newCert = mCertRepot.getX509Certificate(authoritySerial); + manager.importUserCACertPackage(newCert.getEncoded(), mNickname); + + // delete old cert + manager.getInternalKeyStorageToken().getCryptoStore() + .deleteCert(oldCert); + + // reinit signing unit + initSigUnit(false); + } catch (CertificateException e) { + throw new ECAException("Failed to update certificate", e); + } catch (CryptoManager.NotInitializedException e) { + throw new ECAException("CryptoManager not initialized", e); + } catch (CryptoManager.NicknameConflictException e) { + throw new ECAException("Failed to update certificate; nickname conflict", e); + } catch (CryptoManager.UserCertConflictException e) { + throw new ECAException("Failed to update certificate; user cert conflict", e); + } catch (TokenException | NoSuchItemOnTokenException e) { + // really shouldn't happen + throw new ECAException("Failed to update certificate", e); + } + } + private String authorityBaseDN() { return "ou=authorities,ou=" + getId() + "," + getDBSubsystem().getBaseDN(); @@ -2580,6 +2630,8 @@ public class CertificateAuthority addAuthorityEntry(aid, ldapEntry); + X509CertImpl cert = null; + try { // Generate signing key CryptoManager cryptoManager = CryptoManager.getInstance(); @@ -2628,7 +2680,7 @@ public class CertificateAuthority throw new EBaseException("createSubCA: certificate request did not complete; status: " + requestStatus); // Add certificate to nssdb - X509CertImpl cert = request.getExtDataInCert(IEnrollProfile.REQUEST_ISSUED_CERT); + cert = request.getExtDataInCert(IEnrollProfile.REQUEST_ISSUED_CERT); cryptoManager.importCertPackage(cert.getEncoded(), nickname); } catch (Exception e) { // something went wrong; delete just-added entry @@ -2644,11 +2696,65 @@ public class CertificateAuthority throw new ECAException("Error creating lightweight CA certificate: " + e); } - return new CertificateAuthority( + CertificateAuthority ca = new CertificateAuthority( hostCA, subjectX500Name, - aid, this.authorityID, + aid, this.authorityID, cert.getSerialNumber(), nickname, Collections.singleton(thisClone), description, true); + + // Update authority record with serial of issued cert + LDAPModificationSet mods = new LDAPModificationSet(); + mods.add( + LDAPModification.REPLACE, + new LDAPAttribute("authoritySerial", cert.getSerialNumber().toString())); + ca.modifyAuthorityEntry(mods); + + return ca; + } + + /** + * Renew certificate of this CA. + */ + public void renewAuthority(HttpServletRequest httpReq) + throws EBaseException { + if ( + authorityParentID != null + && !authorityParentID.equals(authorityID) + ) { + ICertificateAuthority issuer = getCA(authorityParentID); + issuer.ensureReady(); + } + + IProfileSubsystem ps = (IProfileSubsystem) + CMS.getSubsystem(IProfileSubsystem.ID); + IProfile profile = ps.getProfile("caManualRenewal"); + CertEnrollmentRequest req = CertEnrollmentRequestFactory.create( + new ArgBlock(), profile, httpReq.getLocale()); + req.setSerialNum(new CertId(mCaCert.getSerialNumber())); + RenewalProcessor processor = + new RenewalProcessor("renewAuthority", httpReq.getLocale()); + Map resultMap = + processor.processRenewal(req, httpReq, null); + IRequest requests[] = (IRequest[]) resultMap.get(CAProcessor.ARG_REQUESTS); + IRequest request = requests[0]; + Integer result = request.getExtDataInInteger(IRequest.RESULT); + if (result != null && !result.equals(IRequest.RES_SUCCESS)) + throw new EBaseException("renewAuthority: certificate renewal submission resulted in error: " + result); + RequestStatus requestStatus = request.getRequestStatus(); + if (requestStatus != RequestStatus.COMPLETE) + throw new EBaseException("renewAuthority: certificate renewal did not complete; status: " + requestStatus); + X509CertImpl cert = request.getExtDataInCert(IEnrollProfile.REQUEST_ISSUED_CERT); + authoritySerial = cert.getSerialNumber(); + + // Update authority record with serial of issued cert + LDAPModificationSet mods = new LDAPModificationSet(); + mods.add( + LDAPModification.REPLACE, + new LDAPAttribute("authoritySerial", authoritySerial.toString())); + modifyAuthorityEntry(mods); + + // update cert in NSSDB + checkForNewerCert(); } /** @@ -3041,6 +3147,7 @@ public class CertificateAuthority LDAPAttribute dnAttr = entry.getAttribute("authorityDN"); LDAPAttribute parentAIDAttr = entry.getAttribute("authorityParentID"); LDAPAttribute parentDNAttr = entry.getAttribute("authorityParentDN"); + LDAPAttribute serialAttr = entry.getAttribute("authoritySerial"); if (aidAttr == null || nickAttr == null || dnAttr == null) { CMS.debug("Malformed authority object; required attribute(s) missing: " + entry.getDN()); @@ -3115,6 +3222,10 @@ public class CertificateAuthority parentAID = new AuthorityID((String) parentAIDAttr.getStringValues().nextElement()); + BigInteger serial = null; + if (serialAttr != null) + serial = new BigInteger(serialAttr.getStringValueArray()[0]); + boolean enabled = true; LDAPAttribute enabledAttr = entry.getAttribute("authorityEnabled"); if (enabledAttr != null) { @@ -3125,7 +3236,8 @@ public class CertificateAuthority try { CertificateAuthority ca = new CertificateAuthority( - hostCA, dn, aid, parentAID, keyNick, keyHosts, desc, enabled); + hostCA, dn, aid, parentAID, serial, + keyNick, keyHosts, desc, enabled); caMap.put(aid, ca); entryUSNs.put(aid, newEntryUSN); nsUniqueIds.put(aid, nsUniqueId); diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java index 199ebef1a30c0cb946731ba448320f33611b3605..0993b5c0d8a831f942720f4e1acf67f59da58fda 100644 --- a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java +++ b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java @@ -282,6 +282,37 @@ public class AuthorityService extends PKIService implements AuthorityResource { } @Override + public Response renewCA(String aidString) { + AuthorityID aid = null; + try { + aid = new AuthorityID(aidString); + } catch (IllegalArgumentException e) { + throw new BadRequestException("Bad AuthorityID: " + aidString); + } + + ICertificateAuthority ca = hostCA.getCA(aid); + if (ca == null) + throw new ResourceNotFoundException("CA \"" + aidString + "\" not found"); + + Map auditParams = new LinkedHashMap<>(); + + try { + ca.renewAuthority(servletRequest); + audit(ILogger.SUCCESS, OpDef.OP_MODIFY, aidString, null); + return createNoContentResponse(); + } catch (CADisabledException e) { + auditParams.put("exception", e.toString()); + audit(ILogger.FAILURE, OpDef.OP_MODIFY, aidString, auditParams); + throw new ConflictingOperationException(e.toString()); + } catch (EBaseException e) { + CMS.debug(e); + auditParams.put("exception", e.toString()); + audit(ILogger.FAILURE, OpDef.OP_MODIFY, aidString, auditParams); + throw new PKIException("Error renewing authority: " + e.toString()); + } + } + + @Override public Response deleteCA(String aidString) { AuthorityID aid = null; try { diff --git a/base/common/src/com/netscape/certsrv/authority/AuthorityResource.java b/base/common/src/com/netscape/certsrv/authority/AuthorityResource.java index c6dc696247122b5f07802696c38c2f3517341106..0f8b70ade12c2b4174d5b9880a9c1bbeb35664cf 100644 --- a/base/common/src/com/netscape/certsrv/authority/AuthorityResource.java +++ b/base/common/src/com/netscape/certsrv/authority/AuthorityResource.java @@ -94,6 +94,13 @@ public interface AuthorityResource { @ACLMapping("authorities.modify") public Response disableCA(@PathParam("id") String caIDString); + @POST + @Path("{id}/renew") + @ClientResponseType(entityType=AuthorityData.class) + @AuthMethodMapping("authorities") + @ACLMapping("authorities.modify") + public Response renewCA(@PathParam("id") String caIDString); + @DELETE @Path("{id}") @ClientResponseType(entityType=Void.class) diff --git a/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java b/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java index dd0d1b0851f03b3df8b69f7595a3524e1f9bd9ba..308bfba126cf56d4cccae59a9a1550e34b926f08 100644 --- a/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java +++ b/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java @@ -598,6 +598,12 @@ public interface ICertificateAuthority extends ISubsystem { throws EBaseException; /** + * Renew certificate of CA. + */ + public void renewAuthority(HttpServletRequest httpReq) + throws EBaseException; + + /** * Delete this lightweight CA. */ public void deleteAuthority() diff --git a/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java b/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java index 8efa9162afd37cac8f6ba6dedd056ae36be5ce0e..206d23a5d7898af2e7e93f98080dfa8b009d07ef 100644 --- a/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java +++ b/base/server/cms/src/com/netscape/cms/servlet/cert/RenewalProcessor.java @@ -19,6 +19,7 @@ package com.netscape.cms.servlet.cert; import java.math.BigInteger; import java.security.cert.X509Certificate; +import java.security.Principal; import java.util.ArrayList; import java.util.Date; import java.util.Enumeration; @@ -51,6 +52,7 @@ import com.netscape.certsrv.registry.IPluginInfo; import com.netscape.certsrv.registry.IPluginRegistry; import com.netscape.certsrv.request.IRequest; import com.netscape.cms.profile.input.SerialNumRenewInput; +import com.netscape.cms.realm.PKIPrincipal; import com.netscape.cms.servlet.common.AuthCredentials; import com.netscape.cms.servlet.common.CMSTemplate; import com.netscape.cms.servlet.profile.SSLClientCertProvider; @@ -265,7 +267,12 @@ public class RenewalProcessor extends CertProcessor { context.put("origSubjectDN", origSubjectDN); // before creating the request, authenticate the request - IAuthToken authToken = authenticate(request, origReq, authenticator, context, true, credentials); + IAuthToken authToken = null; + Principal principal = request.getUserPrincipal(); + if (principal instanceof PKIPrincipal) + authToken = ((PKIPrincipal) principal).getAuthToken(); + if (authToken == null) + authToken = authenticate(request, origReq, authenticator, context, true, credentials); // authentication success, now authorize authorize(profileId, renewProfile, authToken); -- 2.5.5 From edewata at redhat.com Sun Jun 5 18:11:50 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 5 Jun 2016 13:11:50 -0500 Subject: [Pki-devel] [PATCH] 0113..0114 Lightweight CAs: renewal support In-Reply-To: <20160604124617.GD4744@dhcp-40-8.bne.redhat.com> References: <20160517052624.GI1323@dhcp-40-8.bne.redhat.com> <113f9b56-b71c-2471-a16a-f45db60d199e@redhat.com> <20160604124348.GC4744@dhcp-40-8.bne.redhat.com> <20160604124617.GD4744@dhcp-40-8.bne.redhat.com> Message-ID: <83a327d6-240e-9dab-243b-3d8efc714c4f@redhat.com> On 6/4/2016 7:46 AM, Fraser Tweedale wrote: >> Updated patch attached. I pass in the HttpServletRequest to >> processRenewal() and use the authToken from the principal if >> available (I also removed the method signature with the IAuthToken >> argument, which was added in the first patch). >> >> If you're happy with the updated patch and I'm not around, would you >> kindly merge it on my behalf? >> >> Thanks for your many reviews this week, Endi. >> Fraser > > Now with patches! ACK. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sun Jun 5 18:12:09 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 5 Jun 2016 13:12:09 -0500 Subject: [Pki-devel] [PATCH] 0122 Modify ExternalProcessKeyRetriever to read JSON In-Reply-To: <20160604110014.GA4744@dhcp-40-8.bne.redhat.com> References: <20160604110014.GA4744@dhcp-40-8.bne.redhat.com> Message-ID: On 6/4/2016 6:00 AM, Fraser Tweedale wrote: > Hi Endi et al, > > Attached patch changes ExternalProcessKeyRetriever to read JSON data > (https://fedorahosted.org/pki/ticket/2351). Would be nice to get > this into 10.2.2 because it will simplify IPA custodia retrieval > helper. > > I am using Jackson for JSON parsing. This is already an implicit > dependency, but should I also add it spec file as explicit > dependency? > > Cheers, > Fraser I think in general we should declare direct dependency on something that we use explicitly because there's no guarantee the indirect dependency won't change. This can be added separately later. ACK. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sun Jun 5 20:39:34 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 5 Jun 2016 15:39:34 -0500 Subject: [Pki-devel] [PATCH] pki-cfu-0131-Ticket-2335-Missing-activity-logs-when-formatting-en.patch In-Reply-To: <57522106.9080601@redhat.com> References: <57522106.9080601@redhat.com> Message-ID: <5e85bfd1-6805-f848-dcb0-71b63b1f1b7b@redhat.com> On 6/3/2016 7:29 PM, Christina Fu wrote: > https://fedorahosted.org/pki/ticket/2335 > > Ticket #2335 Missing activity logs when formatting/enrolling unknown > token This patch adds activity logs for adding unknown token during > format or enrollment > > thanks, > Christina Some comments: 1. The format, enroll, and pin reset operations now generate an additional modify activity log. I think this is unnecessary since we're not changing token record's user-editable attributes such as user ID and policy. Changing system attributes such as token status and key info is part of the operation itself, so it should not generate an extra modify log. 2. Enrolling unknown token fails with this error: TPSEnrollProcessor.generateCertsAfterRenewalRecoveryPolicy:No such token status for this cuid=... That's because the new unknown token was added with UNFORMATTED status and the above method is expecting a FORMATTED status. I think to fix this the token record has to be added earlier as UNFORMATTED, then the format() will change the status to FORMATTED, then the generateCertsAfterRenewalRecoveryPolicy() should work as before. 3. Due to issue #2 I was not able to test unknown token enrollment. If it works it should generate the add, format, and enroll logs. -- Endi S. Dewata From cfu at redhat.com Mon Jun 6 16:14:59 2016 From: cfu at redhat.com (Christina Fu) Date: Mon, 6 Jun 2016 09:14:59 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0131-Ticket-2335-Missing-activity-logs-when-formatting-en.patch In-Reply-To: <5e85bfd1-6805-f848-dcb0-71b63b1f1b7b@redhat.com> References: <57522106.9080601@redhat.com> <5e85bfd1-6805-f848-dcb0-71b63b1f1b7b@redhat.com> Message-ID: <5755A183.6080807@redhat.com> Hi Endi, first, thanks for the review! Please see my response in-line below. thanks, Christina On 06/05/2016 01:39 PM, Endi Sukma Dewata wrote: > On 6/3/2016 7:29 PM, Christina Fu wrote: >> https://fedorahosted.org/pki/ticket/2335 >> >> Ticket #2335 Missing activity logs when formatting/enrolling unknown >> token This patch adds activity logs for adding unknown token during >> format or enrollment >> >> thanks, >> Christina > > Some comments: > > 1. The format, enroll, and pin reset operations now generate an > additional modify activity log. I think this is unnecessary since > we're not changing token record's user-editable attributes such as > user ID and policy. Changing system attributes such as token status > and key info is part of the operation itself, so it should not > generate an extra modify log. my thinking was just to record what happens. First a token is added, then operation (format, enroll, pin_reset) proceed, then if the op succeeds, then token status gets modified to formatted, but if it failed, the token remains added, but stays at unformatted. So, in case of failed cases, there is still a record of that the token being attempted. > > 2. Enrolling unknown token fails with this error: > > TPSEnrollProcessor.generateCertsAfterRenewalRecoveryPolicy:No such > token status for this cuid=... > > That's because the new unknown token was added with UNFORMATTED status > and the above method is expecting a FORMATTED status. ok, I don't recalling seeing such failure when I tested. I will look into this. > > I think to fix this the token record has to be added earlier as > UNFORMATTED, then the format() will change the status to FORMATTED, > then the generateCertsAfterRenewalRecoveryPolicy() should work as before. > > 3. Due to issue #2 I was not able to test unknown token enrollment. If > it works it should generate the add, format, and enroll logs. > From jmagne at redhat.com Mon Jun 6 23:39:43 2016 From: jmagne at redhat.com (John Magne) Date: Mon, 6 Jun 2016 19:39:43 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0070-Fix-coverity-warnings-for-tkstool.patch In-Reply-To: <1523931791.12953324.1465256374773.JavaMail.zimbra@redhat.com> Message-ID: <1997519853.12953347.1465256383335.JavaMail.zimbra@redhat.com> Fix attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0070-Fix-coverity-warnings-for-tkstool.patch Type: text/x-patch Size: 2334 bytes Desc: not available URL: From cfu at redhat.com Tue Jun 7 00:13:53 2016 From: cfu at redhat.com (Christina Fu) Date: Mon, 6 Jun 2016 17:13:53 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0131-Ticket-2335-Missing-activity-logs-when-formatting-en.patch In-Reply-To: <5755A183.6080807@redhat.com> References: <57522106.9080601@redhat.com> <5e85bfd1-6805-f848-dcb0-71b63b1f1b7b@redhat.com> <5755A183.6080807@redhat.com> Message-ID: <575611C1.1060504@redhat.com> received verbal ACK from Endi. Pushed to master: commit b4b401589f540b38874680bc313363678d2d8e13 One odd behavior was observed, which I filed a separate bug for: https://fedorahosted.org/pki/ticket/2354 [TPS] missing activity log entries via UI and CLI (while correctly recorded in LDAP) thanks, Christina On 06/06/2016 09:14 AM, Christina Fu wrote: > Hi Endi, first, thanks for the review! Please see my response in-line > below. > > thanks, > Christina > > On 06/05/2016 01:39 PM, Endi Sukma Dewata wrote: >> On 6/3/2016 7:29 PM, Christina Fu wrote: >>> https://fedorahosted.org/pki/ticket/2335 >>> >>> Ticket #2335 Missing activity logs when formatting/enrolling unknown >>> token This patch adds activity logs for adding unknown token during >>> format or enrollment >>> >>> thanks, >>> Christina >> >> Some comments: >> >> 1. The format, enroll, and pin reset operations now generate an >> additional modify activity log. I think this is unnecessary since >> we're not changing token record's user-editable attributes such as >> user ID and policy. Changing system attributes such as token status >> and key info is part of the operation itself, so it should not >> generate an extra modify log. > my thinking was just to record what happens. First a token is added, > then operation (format, enroll, pin_reset) proceed, then if the op > succeeds, then token status gets modified to formatted, but if it > failed, the token remains added, but stays at unformatted. > So, in case of failed cases, there is still a record of that the token > being attempted. >> >> 2. Enrolling unknown token fails with this error: >> >> TPSEnrollProcessor.generateCertsAfterRenewalRecoveryPolicy:No such >> token status for this cuid=... >> >> That's because the new unknown token was added with UNFORMATTED >> status and the above method is expecting a FORMATTED status. > ok, I don't recalling seeing such failure when I tested. I will look > into this. >> >> I think to fix this the token record has to be added earlier as >> UNFORMATTED, then the format() will change the status to FORMATTED, >> then the generateCertsAfterRenewalRecoveryPolicy() should work as >> before. >> >> 3. Due to issue #2 I was not able to test unknown token enrollment. >> If it works it should generate the add, format, and enroll logs. >> > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Jun 7 11:07:45 2016 From: alee at redhat.com (Ade Lee) Date: Tue, 07 Jun 2016 07:07:45 -0400 Subject: [Pki-devel] Migration procedure from rhcs 8 to 9 Message-ID: <1465297665.21462.13.camel@redhat.com> Hi all, In a followup to my widely popular previous post on migrating a top level CA from RHCS 8 -> 9 (http://pki.fedoraproject.org/wiki/Migrating_ a_ca_with_hsm_using_existing_ca_mechanism), I've added a non-HSM based version which does the migration using a PKCS #12 file to migrate the signing certificate. http://pki.fedoraproject.org/wiki/Migrating_a_CA_using_existing_CA_mech anism Comments/corrections etc. welcomed. Ade From edewata at redhat.com Tue Jun 7 16:02:27 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 7 Jun 2016 11:02:27 -0500 Subject: [Pki-devel] Migration procedure from rhcs 8 to 9 In-Reply-To: <1465297665.21462.13.camel@redhat.com> References: <1465297665.21462.13.camel@redhat.com> Message-ID: On 6/7/2016 6:07 AM, Ade Lee wrote: > Hi all, > > In a followup to my widely popular previous post on migrating a top > level CA from RHCS 8 -> 9 (http://pki.fedoraproject.org/wiki/Migrating_ > a_ca_with_hsm_using_existing_ca_mechanism), I've added a non-HSM based > version which does the migration using a PKCS #12 file to migrate the > signing certificate. > > http://pki.fedoraproject.org/wiki/Migrating_a_CA_using_existing_CA_mech > anism > > Comments/corrections etc. welcomed. > > Ade I fixed the version numbers in both pages to clarify that these instructions are for RHCS 9.1. I think in practice it's unlikely that someone would put a hostname in the following parameters so I'd suggest we remove it from the example (or replace it with a domain name instead of hostname): pki_ds_base_dn=dc=host1.example.com-pki-rootCA pki_ds_database=host1.example.com-pki-rootCA -- Endi S. Dewata From edewata at redhat.com Tue Jun 7 19:07:33 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 7 Jun 2016 14:07:33 -0500 Subject: [Pki-devel] [PATCH] 763-764 Fixed TPS VLV indexes. Message-ID: The TPS VLV indexes have been modified to fix the filters and sort orders. Upgrade instruction is available here: http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x#Fixing_VLV_filters_and_sort_orders https://fedorahosted.org/pki/ticket/2354 https://fedorahosted.org/pki/ticket/2263 https://fedorahosted.org/pki/ticket/2269 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0763-Fixed-TPS-VLV-filters.patch Type: text/x-patch Size: 4037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0764-Fixed-TPS-VLV-sort-orders.patch Type: text/x-patch Size: 16204 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 8 13:43:11 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 8 Jun 2016 08:43:11 -0500 Subject: [Pki-devel] [PATCH] 765 Added TPS VLV management CLI. Message-ID: A set of pki-server commands has been added to simplify upgrading TPS VLV indexes. https://fedorahosted.org/pki/ticket/2354 https://fedorahosted.org/pki/ticket/2263 https://fedorahosted.org/pki/ticket/2269 Upgrade instruction: http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x#Fixing_VLV_filters_and_sort_orders -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0765-Added-TPS-VLV-management-CLI.patch Type: text/x-patch Size: 22975 bytes Desc: not available URL: From alee at redhat.com Wed Jun 8 14:06:45 2016 From: alee at redhat.com (Ade Lee) Date: Wed, 08 Jun 2016 10:06:45 -0400 Subject: [Pki-devel] [PATCH] 765 Added TPS VLV management CLI. In-Reply-To: References: Message-ID: <1465394805.29462.2.camel@redhat.com> Looks pretty good. A new and improved version of the KRA VLV CLIs I wrote last week. tps-db-vlv-delete does not have a --generate-ldif option. Are you going to add that? Also, you should probably add a task to add a kra-db-vlv-find option so that we have parity. We can set that for 10.4. Ade On Wed, 2016-06-08 at 08:43 -0500, Endi Sukma Dewata wrote: > A set of pki-server commands has been added to simplify upgrading > TPS VLV indexes. > > https://fedorahosted.org/pki/ticket/2354 > https://fedorahosted.org/pki/ticket/2263 > https://fedorahosted.org/pki/ticket/2269 > > Upgrade instruction: > http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x#Fix > ing_VLV_filters_and_sort_orders > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Jun 8 14:15:37 2016 From: alee at redhat.com (Ade Lee) Date: Wed, 08 Jun 2016 10:15:37 -0400 Subject: [Pki-devel] [PATCH] 322 - fix man page subjects Message-ID: <1465395337.29462.5.camel@redhat.com> This is a simple one: commit d0a5e6c9f9d0a87ad4e5d96f2c911449889e579a Author: Ade Lee Date: Wed Jun 8 09:41:31 2016 -0400 Fix name fields in man pages for correct man -k output Ticket 1563 Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0322-Fix-name-fields-in-man-pages-for-correct-man-k-outpu.patch Type: text/x-patch Size: 4109 bytes Desc: not available URL: From jmagne at redhat.com Wed Jun 8 17:58:29 2016 From: jmagne at redhat.com (John Magne) Date: Wed, 8 Jun 2016 13:58:29 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0071-UdnPwdDirAuth-authentication-plugin-instance-is-not-.patch In-Reply-To: <1900160992.13618352.1465408590504.JavaMail.zimbra@redhat.com> Message-ID: <239521752.13620152.1465408709073.JavaMail.zimbra@redhat.com> UdnPwdDirAuth authentication plugin instance is not working. Ticket #1579 : UdnPwdDirAuth authentication plugin instance is not working. Since this class no longer works, we felt it best to just remove it from the server. This patch removes the references and files associated with this auth method,including the plugin itself, so intrepid individuals will not be tempted to manually configure this auth method. QE has nicely decided to independently remove the tests associated with this plugin already. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0071-UdnPwdDirAuth-authentication-plugin-instance-is-not-.patch Type: text/x-patch Size: 33887 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 8 18:02:26 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 8 Jun 2016 13:02:26 -0500 Subject: [Pki-devel] [PATCH] 765 Added TPS VLV management CLI. In-Reply-To: <1465394805.29462.2.camel@redhat.com> References: <1465394805.29462.2.camel@redhat.com> Message-ID: <02132db8-2099-ef2e-ee45-a77fed3ec1d7@redhat.com> Thanks for the feedback. Please take a look at the new patches #765-1 and #766. On 6/8/2016 9:06 AM, Ade Lee wrote: > Looks pretty good. A new and improved version of the KRA VLV CLIs I > wrote last week. As discussed on IRC the common code should be refactored in the future: https://fedorahosted.org/pki/ticket/2355 > tps-db-vlv-delete does not have a --generate-ldif option. Are you > going to add that? I've added an option to generate an LDIF file to delete old VLVs based on the vlv.ldif (so it doesn't need to contact the server). > Also, you should probably add a task to add a kra-db-vlv-find option so > that we have parity. We can set that for 10.4. The kra-db-vlv-find has been added in the new patch. I also modified kra-db-vlv-reindex to wait for the operation to complete. The wiki page has been updated as well: http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x#Fixing_VLV_filters_and_sort_orders -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0765-1-Added-TPS-VLV-management-CLI.patch Type: text/x-patch Size: 18523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0766-Updated-KRA-VLV-management-CLI.patch Type: text/x-patch Size: 10921 bytes Desc: not available URL: From alee at redhat.com Wed Jun 8 20:03:06 2016 From: alee at redhat.com (Ade Lee) Date: Wed, 08 Jun 2016 16:03:06 -0400 Subject: [Pki-devel] [PATCH] 765 Added TPS VLV management CLI. In-Reply-To: <02132db8-2099-ef2e-ee45-a77fed3ec1d7@redhat.com> References: <1465394805.29462.2.camel@redhat.com> <02132db8-2099-ef2e-ee45-a77fed3ec1d7@redhat.com> Message-ID: <1465416186.29462.6.camel@redhat.com> ACK On Wed, 2016-06-08 at 13:02 -0500, Endi Sukma Dewata wrote: > Thanks for the feedback. Please take a look at the new patches #765-1 > and #766. > > On 6/8/2016 9:06 AM, Ade Lee wrote: > > Looks pretty good. A new and improved version of the KRA VLV CLIs > > I > > wrote last week. > > As discussed on IRC the common code should be refactored in the > future: > https://fedorahosted.org/pki/ticket/2355 > > > tps-db-vlv-delete does not have a --generate-ldif option. Are you > > going to add that? > > I've added an option to generate an LDIF file to delete old VLVs > based > on the vlv.ldif (so it doesn't need to contact the server). > > > Also, you should probably add a task to add a kra-db-vlv-find > > option so > > that we have parity. We can set that for 10.4. > > The kra-db-vlv-find has been added in the new patch. I also modified > kra-db-vlv-reindex to wait for the operation to complete. > > The wiki page has been updated as well: > http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x#Fix > ing_VLV_filters_and_sort_orders > From edewata at redhat.com Wed Jun 8 21:19:01 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 8 Jun 2016 16:19:01 -0500 Subject: [Pki-devel] [PATCH] 765 Added TPS VLV management CLI. In-Reply-To: <1465416186.29462.6.camel@redhat.com> References: <1465394805.29462.2.camel@redhat.com> <02132db8-2099-ef2e-ee45-a77fed3ec1d7@redhat.com> <1465416186.29462.6.camel@redhat.com> Message-ID: <6a54e3b4-9a17-a0a5-4a7f-e1bba934fe2b@redhat.com> On 6/8/2016 3:03 PM, Ade Lee wrote: > ACK Thanks! Pushed to master. -- Endi S. Dewata From cfu at redhat.com Fri Jun 10 01:13:30 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 9 Jun 2016 18:13:30 -0700 Subject: [Pki-devel] [PATCH] 763-764 Fixed TPS VLV indexes. In-Reply-To: References: Message-ID: <575A143A.3090705@redhat.com> I was able to follow the VLV upgrade instruction and tried out the patches. Love the reverse activities order. tokens too. The previously "missing" activities now also show up. Since I'm not familiar with the area of the code you touched, I can give you ACK on the merit that they seem to work when I applied. You could ask for code-level review from others, but it's up to you. ACK thanks, Christina On 06/07/2016 12:07 PM, Endi Sukma Dewata wrote: > The TPS VLV indexes have been modified to fix the filters and sort > orders. Upgrade instruction is available here: > > http://pki.fedoraproject.org/wiki/Database_Upgrade_for_PKI_10.3.x#Fixing_VLV_filters_and_sort_orders > > > https://fedorahosted.org/pki/ticket/2354 > https://fedorahosted.org/pki/ticket/2263 > https://fedorahosted.org/pki/ticket/2269 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Fri Jun 10 14:54:01 2016 From: alee at redhat.com (Ade Lee) Date: Fri, 10 Jun 2016 10:54:01 -0400 Subject: [Pki-devel] [PATCH] more simple man page patches Message-ID: <1465570441.6410.4.camel@redhat.com> Please review, Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0323-Add-man-page-info-for-number-range-parameters.patch Type: text/x-patch Size: 2023 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0324-Add-man-page-entry-for-pki-server-instance-cert-expo.patch Type: text/x-patch Size: 1746 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 10 15:11:47 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 10 Jun 2016 10:11:47 -0500 Subject: [Pki-devel] [PATCH] 763-764 Fixed TPS VLV indexes. In-Reply-To: <575A143A.3090705@redhat.com> References: <575A143A.3090705@redhat.com> Message-ID: On 6/9/2016 8:13 PM, Christina Fu wrote: > I was able to follow the VLV upgrade instruction and tried out the > patches. Love the reverse activities order. tokens too. The > previously "missing" activities now also show up. > Since I'm not familiar with the area of the code you touched, I can give > you ACK on the merit that they seem to work when I applied. You could > ask for code-level review from others, but it's up to you. > > ACK > thanks, > Christina Thanks! I think the code changes are quite straight forward, so I pushed the patches to master. Basically we're preserving the "-" sign when converting Java fields into LDAP attributes so "-date" in Java will match "-dateOfCreate" in VLV. -- Endi S. Dewata From edewata at redhat.com Fri Jun 10 15:29:51 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 10 Jun 2016 10:29:51 -0500 Subject: [Pki-devel] [PATCH] 767 Fixed VLV usage in TPS token and activity services. Message-ID: <8cd67dc8-a292-a465-afea-10ccd3c23948@redhat.com> The TPS token and activity services have been modified to use VLV only when the search filter matches the VLV, which is the default filter when there is no search keyword/attributes specified by the client. In other cases the services will use a normal search. https://fedorahosted.org/pki/ticket/2342 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0767-Fixed-VLV-usage-in-TPS-token-and-activity-services.patch Type: text/x-patch Size: 9654 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 10 15:41:52 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 10 Jun 2016 10:41:52 -0500 Subject: [Pki-devel] [PATCH] more simple man page patches In-Reply-To: <1465570441.6410.4.camel@redhat.com> References: <1465570441.6410.4.camel@redhat.com> Message-ID: On 6/10/2016 9:54 AM, Ade Lee wrote: > Please review, > > Thanks, > Ade ACK. Pushed to master. -- Endi S. Dewata From mharmsen at redhat.com Fri Jun 10 17:39:56 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 10 Jun 2016 11:39:56 -0600 Subject: [Pki-devel] Karma Request for Dogtag 10.3.2 on Fedora 24 Message-ID: <575AFB6C.1010300@redhat.com> The following candidate builds of Dogtag 10.3.2 for Fedora 24 consist of the following: * dogtag-pki-theme-10.3.2-2.fc24 * dogtag-pki-10.3.2-1.fc24 * pki-core-10.3.2-3.fc24 * pki-console-10.3.2-2.fc24 Please provide Karma for these builds in Bodhi located at: * dogtag-pki-theme-10.3.2-2.fc24 * dogtag-pki-10.3.2-1.fc24 * pki-core-10.3.2-3.fc24 * pki-console-10.3.2-2.fc24 Additionally, the following builds have been provided for Fedora 25 (rawhide): * dogtag-pki-theme-10.3.2-2.fc25 * dogtag-pki-10.3.2-1.fc25 * pki-core-10.3.2-3.fc25 * pki-console-10.3.2-2.fc25 Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Sun Jun 12 23:46:58 2016 From: alee at redhat.com (Ade Lee) Date: Sun, 12 Jun 2016 19:46:58 -0400 Subject: [Pki-devel] [PATCH] patch to fix pki ca-kraconnector and add man page Message-ID: <1465775218.10471.4.camel@redhat.com> commit 01af3ee5928de2bacaf62210672e1e51524bd41d Author: Ade Lee Date: Fri Jun 10 22:18:03 2016 -0400 Add man page and clarify CLI for kra-connector Ended up changing the CLI for kra-connector to make things a lot clearer as discussed with Endi. Tested adding and removing host/port and installing and removing KRAs (which call the install/remove connector calls). Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0325-Add-man-page-and-clarify-CLI-for-kra-connector.patch Type: text/x-patch Size: 22218 bytes Desc: not available URL: From akahat at redhat.com Mon Jun 13 07:22:57 2016 From: akahat at redhat.com (Amol Kahat) Date: Mon, 13 Jun 2016 12:52:57 +0530 Subject: [Pki-devel] Fixes 1339263 issue. Message-ID: <575E5F51.7040102@redhat.com> Hi, I fixes bugzilla issue no 1339263. Please review this patch. PFA. Thank You. Amol K. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Description-Fixed-help-option-for-instance-show-inst.patch Type: text/x-patch Size: 5787 bytes Desc: not available URL: From edewata at redhat.com Mon Jun 13 14:36:22 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 13 Jun 2016 09:36:22 -0500 Subject: [Pki-devel] Fixes 1339263 issue. In-Reply-To: <575E5F51.7040102@redhat.com> References: <575E5F51.7040102@redhat.com> Message-ID: <6f9edc91-a6c9-a6fe-0d6b-9d98286c9aaf@redhat.com> On 6/13/2016 2:22 AM, Amol Kahat wrote: > Hi, > > I fixes bugzilla issue no 1339263. > Please review this patch. > > PFA. > > Thank You. > > Amol K. Thanks for the patch! Just one issue, in InstanceMigrateCLI the tomcat_version needs to stay where it was since it's getting the value from --tomcat option. ACK. I fixed the patch and pushed it to master. -- Endi S. Dewata From mharmsen at redhat.com Mon Jun 13 15:43:00 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 13 Jun 2016 09:43:00 -0600 Subject: [Pki-devel] Karma Request for Dogtag 10.3.2 on Fedora 24 In-Reply-To: <575AFB6C.1010300@redhat.com> References: <575AFB6C.1010300@redhat.com> Message-ID: <575ED484.5010906@redhat.com> Everyone, Please, note the updated builds of pki-core. Thanks, -- Matt On 06/10/2016 11:39 AM, Matthew Harmsen wrote: > The following candidate builds of Dogtag 10.3.2 for Fedora 24 consist > of the following: > > * dogtag-pki-theme-10.3.2-2.fc24 > > * dogtag-pki-10.3.2-1.fc24 > > * pki-core-10.3.2-3.fc24 > > * pki-core-10.3.2-4.fc24 > * pki-console-10.3.2-2.fc24 > > > Please provide Karma for these builds in Bodhi located at: > > * dogtag-pki-theme-10.3.2-2.fc24 > > * dogtag-pki-10.3.2-1.fc24 > > * pki-core-10.3.2-3.fc24 > > * pki-core-10.3.2-4.fc24 > * pki-console-10.3.2-2.fc24 > > > Additionally, the following builds have been provided for Fedora 25 > (rawhide): > > * dogtag-pki-theme-10.3.2-2.fc25 > > * dogtag-pki-10.3.2-1.fc25 > > * pki-core-10.3.2-3.fc25 > > * pki-core-10.3.2-4.fc25 > * pki-console-10.3.2-2.fc25 > > > Thanks, > -- Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Mon Jun 13 15:53:56 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 13 Jun 2016 09:53:56 -0600 Subject: [Pki-devel] Updated External EPEL CentOS 7 COPR builds are now available . . . Message-ID: <575ED714.5060100@redhat.com> An updated external EPEL CentOS 7 COPR repo is available now available which contains Dogtag 10.3.2 builds: * https://copr.fedorainfracloud.org/coprs/g/pki/10.3.2/repo/epel-7/group_pki-10.3.2-epel-7.repo [group_pki-10.3.2] name=Copr repo for 10.3.2 owned by @pki baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.2/epel-7-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.2/pubkey.gpg enabled=1 enabled_metadata=1 -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Jun 13 19:09:17 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 13 Jun 2016 14:09:17 -0500 Subject: [Pki-devel] [PATCH] patch to fix pki ca-kraconnector and add man page In-Reply-To: <1465775218.10471.4.camel@redhat.com> References: <1465775218.10471.4.camel@redhat.com> Message-ID: <97359430-7f84-278d-ce56-86aa14862337@redhat.com> On 6/12/2016 6:46 PM, Ade Lee wrote: > commit 01af3ee5928de2bacaf62210672e1e51524bd41d > Author: Ade Lee > Date: Fri Jun 10 22:18:03 2016 -0400 > > Add man page and clarify CLI for kra-connector > > Ended up changing the CLI for kra-connector to make things a lot > clearer as discussed with Endi. > > Tested adding and removing host/port and installing and removing KRAs > (which call the install/remove connector calls). > > Please review. > Ade I think there's still a confusion between KRA connector vs host. To my understanding there's only one connector but it can have multiple hosts. When we install KRA initially we create a connector with one host. In subsequent KRA cloning we're only adding another host to the same connector, we're not adding another connector. Similarly when we remove a KRA clone we're only removing a host, but when the last KRA is removed the connector is automatically removed as well (although it doesn't have to be). Ideally the CLIs and the configuration file should reflect that distinction properly. We can revise it in 10.4. For now I just added some small changes to clarify the CLI messages and the man page. I pushed the revised patch to master. -- Endi S. Dewata From edewata at redhat.com Tue Jun 14 00:24:01 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 13 Jun 2016 19:24:01 -0500 Subject: [Pki-devel] [PATCH] 768 Added pki pkcs12-cert-mod command. Message-ID: <89778995-db70-9c85-208f-638a6cebdf12@redhat.com> A new CLI has been added to update the certificate trust flags in PKCS #12 file which will be useful to import OpenSSL certificates. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0768-Added-pki-pkcs12-cert-mod-command.patch Type: text/x-patch Size: 7551 bytes Desc: not available URL: From ftweedal at redhat.com Tue Jun 14 02:38:37 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 14 Jun 2016 12:38:37 +1000 Subject: [Pki-devel] [PATCH] 0123 Do not attempt cert update unless signing key is present Message-ID: <20160614023837.GW4744@dhcp-40-8.bne.redhat.com> Hi all, The attached patch fixes https://fedorahosted.org/pki/ticket/2359. Please review for inclusion in 10.3.3. Thanks, Fraser -------------- next part -------------- From c9f7d91295f673055201ca528ebdadd9018e4978 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 14 Jun 2016 12:19:25 +1000 Subject: [PATCH] Do not attempt cert update unless signing key is present If an authority entry is read with the authoritySerial attribute, and the serial differs from the known serial or the serial was previously unknown, Dogtag attempts to update the certificate in the NSSDB. The procedure is carried out during initialisation, and if it fails an exception is thrown, causing the CA to remain unknown. If the signing key is not yet in the NSSDB, the update is certain to fail. This can happen e.g. if CA is created on one clone while another clone is down. When the other clone comes up, it will immediately see the authoritySerial and trigger this scenario. To avoid this scenario, only attempt to update the certificate if the signing unit initialisation completed successfully, implying the presence of the signing key. Fixes: https://fedorahosted.org/pki/ticket/2359 --- base/ca/src/com/netscape/ca/CertificateAuthority.java | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java index c9de9f9a58ce91a56043e21d47cd63020b20c085..e501380c8dd6d2d6fc400ad9f43677bfae7e258e 100644 --- a/base/ca/src/com/netscape/ca/CertificateAuthority.java +++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java @@ -517,8 +517,9 @@ public class CertificateAuthority } // init signing unit & CA cert. + boolean initSigUnitSucceeded = false; try { - initSigUnit(/* retrieveKeys */ true); + initSigUnitSucceeded = initSigUnit(/* retrieveKeys */ true); // init default CA attributes like cert version, validity. initDefCaAttrs(); @@ -531,7 +532,10 @@ public class CertificateAuthority } } - checkForNewerCert(); + /* Don't try to update the cert unless we already have + * the cert and key. */ + if (initSigUnitSucceeded) + checkForNewerCert(); mUseNonces = mConfig.getBoolean("enableNonces", true); mMaxNonces = mConfig.getInteger("maxNumberOfNonces", 100); -- 2.5.5 From akahat at redhat.com Tue Jun 14 10:41:03 2016 From: akahat at redhat.com (Amol Kahat) Date: Tue, 14 Jun 2016 16:11:03 +0530 Subject: [Pki-devel] Fixes 1339263 issue. In-Reply-To: <6f9edc91-a6c9-a6fe-0d6b-9d98286c9aaf@redhat.com> References: <575E5F51.7040102@redhat.com> <6f9edc91-a6c9-a6fe-0d6b-9d98286c9aaf@redhat.com> Message-ID: <575FDF3F.20905@redhat.com> Endi thanks. On 06/13/2016 08:06 PM, Endi Sukma Dewata wrote: > On 6/13/2016 2:22 AM, Amol Kahat wrote: >> Hi, >> >> I fixes bugzilla issue no 1339263. >> Please review this patch. >> >> PFA. >> >> Thank You. >> >> Amol K. > > Thanks for the patch! > > Just one issue, in InstanceMigrateCLI the tomcat_version needs to stay > where it was since it's getting the value from --tomcat option. > > ACK. I fixed the patch and pushed it to master. > From akahat at redhat.com Tue Jun 14 11:14:56 2016 From: akahat at redhat.com (Amol Kahat) Date: Tue, 14 Jun 2016 16:44:56 +0530 Subject: [Pki-devel] Patch for pki-server cli and man page. Message-ID: <575FE730.6010900@redhat.com> Hi, I fixed the bugzilla issue 1341953. And enhance code of pki-server instance-start. And also i fixed man page for pki-server instance-cert. Please review this patches. PFA. Thanks Amol K -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-pki-server-instance-start-instance-command.patch Type: text/x-patch Size: 2502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-entry-of-pki-server-instance-cert-command-in-m.patch Type: text/x-patch Size: 1433 bytes Desc: not available URL: From edewata at redhat.com Tue Jun 14 15:17:34 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 14 Jun 2016 10:17:34 -0500 Subject: [Pki-devel] [PATCH] 769 Fixed problem with headerless PKCS #7 data. Message-ID: <5273b500-336a-8557-6cc5-5c34ebe53d19@redhat.com> Due to a recently added validation code, the headerless PKCS #7 data generated by IPA needs to be joined into a single line before storing it in CS.cfg. Pushed to master under one-liner/trivial rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0769-Fixed-problem-with-multi-line-headerless-PKCS-7-data.patch Type: text/x-patch Size: 1349 bytes Desc: not available URL: From edewata at redhat.com Tue Jun 14 18:56:25 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 14 Jun 2016 13:56:25 -0500 Subject: [Pki-devel] [PATCH] 0770 Fixed REST response format. Message-ID: Some REST services have been fixed to return the response in XML format by default. https://fedorahosted.org/pki/ticket/1276 Pushed under one-liner/trivial rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0770-Fixed-REST-response-format.patch Type: text/x-patch Size: 3417 bytes Desc: not available URL: From edewata at redhat.com Tue Jun 14 22:51:41 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 14 Jun 2016 17:51:41 -0500 Subject: [Pki-devel] Patch for pki-server cli and man page. In-Reply-To: <575FE730.6010900@redhat.com> References: <575FE730.6010900@redhat.com> Message-ID: <494d0be3-8ff4-acba-1ce5-c7eba1f4ce9e@redhat.com> On 6/14/2016 6:14 AM, Amol Kahat wrote: > Hi, > > I fixed the bugzilla issue 1341953. And enhance code of pki-server > instance-start. > > And also i fixed man page for pki-server instance-cert. > > Please review this patches. > > PFA. > > > Thanks > Amol K Thanks! I pushed the patches to master with some revisions: * the if-statements were restructured to reduce indentations * if the instance doesn't exist the code calls sys.exit(1) * some output messages were modified for consistency -- Endi S. Dewata From jmagne at redhat.com Tue Jun 14 23:07:49 2016 From: jmagne at redhat.com (John Magne) Date: Tue, 14 Jun 2016 19:07:49 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0072-Revocation-failure-causes-AUDIT_PRIVATE_KEY_ARCHIVE_.patch In-Reply-To: <487490868.15352511.1465945662598.JavaMail.zimbra@redhat.com> Message-ID: <1629734899.15352521.1465945669018.JavaMail.zimbra@redhat.com> Revocation failure causes AUDIT_PRIVATE_KEY_ARCHIVE_REQUEST The fix here is to make sure no archive related audits get issued for doing things other than key archivals. Other operations such as revoking and unrevoking cert in the code path laready have audit logs issued separately for success or failure. Ticket #2340. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0072-Revocation-failure-causes-AUDIT_PRIVATE_KEY_ARCHIVE_.patch Type: text/x-patch Size: 17370 bytes Desc: not available URL: From mharmsen at redhat.com Tue Jun 14 23:36:27 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 14 Jun 2016 17:36:27 -0600 Subject: [Pki-devel] [pki-devel][PATCH] 0070-Fix-coverity-warnings-for-tkstool.patch In-Reply-To: <1997519853.12953347.1465256383335.JavaMail.zimbra@redhat.com> References: <1997519853.12953347.1465256383335.JavaMail.zimbra@redhat.com> Message-ID: <576094FB.3060900@redhat.com> On 06/06/2016 05:39 PM, John Magne wrote: > Fix attached. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK Personally, I always prefer the use of enclosing braces "{ . . . }" after a conditional even when it only has one line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Jun 15 00:40:12 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 14 Jun 2016 19:40:12 -0500 Subject: [Pki-devel] [PATCH] 0123 Do not attempt cert update unless signing key is present In-Reply-To: <20160614023837.GW4744@dhcp-40-8.bne.redhat.com> References: <20160614023837.GW4744@dhcp-40-8.bne.redhat.com> Message-ID: On 6/13/2016 9:38 PM, Fraser Tweedale wrote: > Hi all, > > The attached patch fixes https://fedorahosted.org/pki/ticket/2359. > Please review for inclusion in 10.3.3. > > Thanks, > Fraser It looks like the initSignUnit() is only called with retrieveKeys=true in init(). So the code that starts the key retriever thread probably can be moved out, becoming something like this: initDefCaAttrs(); try { initSignUnit(); checkForNewerCert(); } catch (CAMissingCertException | CAMissingKeyException e) { // start key retriever thread } catch (EBaseException e) { ... } I think it would clarify a little bit how the missing cert/key is handled. So if I understand correctly if the cert/key is missing the LWCA object will still be created and registered, but it will be disabled (hasKeys=false)? When the key retriever thread is complete, will it automatically reinitialize and enable the LWCA object? Regardless, feel free to push the patch as is. -- Endi S. Dewata From mharmsen at redhat.com Wed Jun 15 01:06:31 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 14 Jun 2016 19:06:31 -0600 Subject: [Pki-devel] Karma Request for Dogtag 10.3.2 on Fedora 24 In-Reply-To: <575ED484.5010906@redhat.com> References: <575AFB6C.1010300@redhat.com> <575ED484.5010906@redhat.com> Message-ID: <5760AA17.40203@redhat.com> On 06/13/2016 09:43 AM, Matthew Harmsen wrote: > Everyone, > > Please, note the updated builds of pki-core. Sorry, more updated builds. > > Thanks, > -- Matt > > On 06/10/2016 11:39 AM, Matthew Harmsen wrote: >> The following candidate builds of Dogtag 10.3.2 for Fedora 24 consist >> of the following: >> >> * dogtag-pki-theme-10.3.2-2.fc24 >> >> * dogtag-pki-10.3.2-1.fc24 >> >> * dogtag-pki-10.3.2-2.fc24 >> * pki-core-10.3.2-3.fc24 >> >> > * pki-core-10.3.2-4.fc24 > > >> * pki-console-10.3.2-2.fc24 >> >> * pki-console-10.3.2-3.fc24 >> Please provide Karma for these builds in Bodhi located at: >> >> * dogtag-pki-theme-10.3.2-2.fc24 >> >> * dogtag-pki-10.3.2-1.fc24 >> >> * dogtag-pki-10.3.2-2.fc24 >> * pki-core-10.3.2-3.fc24 >> >> > * pki-core-10.3.2-4.fc24 > > >> * pki-console-10.3.2-2.fc24 >> >> * pki-console-10.3.2-3.fc24 >> Additionally, the following builds have been provided for Fedora 25 >> (rawhide): >> >> * dogtag-pki-theme-10.3.2-2.fc25 >> >> * dogtag-pki-10.3.2-1.fc25 >> >> * dogtag-pki-10.3.2-2.fc25 >> * pki-core-10.3.2-3.fc25 >> >> > * pki-core-10.3.2-4.fc25 > > >> * pki-console-10.3.2-2.fc25 >> >> * pki-console-10.3.2-3.fc25 >> Thanks, >> -- Matt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed Jun 15 01:53:00 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 15 Jun 2016 11:53:00 +1000 Subject: [Pki-devel] [PATCH] 0123 Do not attempt cert update unless signing key is present In-Reply-To: References: <20160614023837.GW4744@dhcp-40-8.bne.redhat.com> Message-ID: <20160615015300.GC4744@dhcp-40-8.bne.redhat.com> On Tue, Jun 14, 2016 at 07:40:12PM -0500, Endi Sukma Dewata wrote: > On 6/13/2016 9:38 PM, Fraser Tweedale wrote: > > Hi all, > > > > The attached patch fixes https://fedorahosted.org/pki/ticket/2359. > > Please review for inclusion in 10.3.3. > > > > Thanks, > > Fraser > > It looks like the initSignUnit() is only called with retrieveKeys=true in > init(). So the code that starts the key retriever thread probably can be > moved out, becoming something like this: > > initDefCaAttrs(); > > try { > initSignUnit(); > checkForNewerCert(); > > } catch (CAMissingCertException | CAMissingKeyException e) { > // start key retriever thread > > } catch (EBaseException e) { > ... > } > > I think it would clarify a little bit how the missing cert/key is handled. > Yes, that will be a nice refactor. I may send a patch for that soon. > So if I understand correctly if the cert/key is missing the LWCA object will > still be created and registered, but it will be disabled (hasKeys=false)? > > When the key retriever thread is complete, will it automatically > reinitialize and enable the LWCA object? > Yes to both question. The bug was that an exception could be thrown when constructing the LWCA object (thus it was not registered). Key retrieval had been initiated and successfully retrieved the key, but there was no LWCA object to reinitialise. > Regardless, feel free to push the patch as is. > Thanks, pushed to master (41aef5254c20301851716ef46b614d185b33a87b) From edewata at redhat.com Wed Jun 15 04:14:44 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 14 Jun 2016 23:14:44 -0500 Subject: [Pki-devel] [PATCH] 771 Refactored SystemConfigService.processCerts(). Message-ID: To simplify future enhancements the code that processes each certificate in SystemConfigService.processCerts() has been moved into a separate method. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0771-Refactored-SystemConfigService.processCerts.patch Type: text/x-patch Size: 16452 bytes Desc: not available URL: From ftweedal at redhat.com Wed Jun 15 08:36:47 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 15 Jun 2016 18:36:47 +1000 Subject: [Pki-devel] [PATCH] 771 Refactored SystemConfigService.processCerts(). In-Reply-To: References: Message-ID: <20160615083647.GF4744@dhcp-40-8.bne.redhat.com> On Tue, Jun 14, 2016 at 11:14:44PM -0500, Endi Sukma Dewata wrote: > To simplify future enhancements the code that processes each > certificate in SystemConfigService.processCerts() has been moved > into a separate method. > ACK. From edewata at redhat.com Wed Jun 15 16:36:28 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 15 Jun 2016 11:36:28 -0500 Subject: [Pki-devel] [PATCH] 772 Updated instructions to customize TPS token lifecycle. Message-ID: <487925d6-6e1f-6cb4-387b-e0509ba99294@redhat.com> The TPS's CS.cfg and token-states.properties have been updated to include instructions to customize token state transitions and labels. https://fedorahosted.org/pki/ticket/2300 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0772-Updated-instructions-to-customize-TPS-token-lifecycl.patch Type: text/x-patch Size: 5270 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 15 21:36:49 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 15 Jun 2016 16:36:49 -0500 Subject: [Pki-devel] [PATCH] 773 Migrating system certificates. Message-ID: Attached is a preliminary patch to provide a mechanism to import all existing CA system certificates into a new CA instance. It's not ready to be checked in yet. It's posted for evaluation only. Here's the doc: http://pki.fedoraproject.org/wiki/Installing_CA_with_Existing_System_Certificates The patch has only been tested with PKCS #12 installation. It has not been tested with HSM. Also currently it breaks the external CA case. Nevertheless, I think it's pretty close to complete, but it will need more thorough testing. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0773-Migrating-system-certificates.patch Type: text/x-patch Size: 19982 bytes Desc: not available URL: From ftweedal at redhat.com Thu Jun 16 00:22:38 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 16 Jun 2016 10:22:38 +1000 Subject: [Pki-devel] [PATCH] 767 Fixed VLV usage in TPS token and activity services. In-Reply-To: <8cd67dc8-a292-a465-afea-10ccd3c23948@redhat.com> References: <8cd67dc8-a292-a465-afea-10ccd3c23948@redhat.com> Message-ID: <20160616002238.GJ4744@dhcp-40-8.bne.redhat.com> On Fri, Jun 10, 2016 at 10:29:51AM -0500, Endi Sukma Dewata wrote: > The TPS token and activity services have been modified to use VLV > only when the search filter matches the VLV, which is the default > filter when there is no search keyword/attributes specified by > the client. In other cases the services will use a normal search. > > https://fedorahosted.org/pki/ticket/2342 > > -- > Endi S. Dewata > Code changes look good. Might be nice to construct the (Token|Activity)Collection objects inside the find* methods rather than constructing it at call side and passing it in to be populated. Just a nit, though. Searching/filtering continues to work as expected. ACK. From ftweedal at redhat.com Thu Jun 16 00:35:26 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 16 Jun 2016 10:35:26 +1000 Subject: [Pki-devel] [PATCH] 768 Added pki pkcs12-cert-mod command. In-Reply-To: <89778995-db70-9c85-208f-638a6cebdf12@redhat.com> References: <89778995-db70-9c85-208f-638a6cebdf12@redhat.com> Message-ID: <20160616003525.GK4744@dhcp-40-8.bne.redhat.com> On Mon, Jun 13, 2016 at 07:24:01PM -0500, Endi Sukma Dewata wrote: > A new CLI has been added to update the certificate trust flags in > PKCS #12 file which will be useful to import OpenSSL certificates. > Tested; does what it says on the tin. ACK. Cheers, Fraser From ftweedal at redhat.com Thu Jun 16 00:47:05 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 16 Jun 2016 10:47:05 +1000 Subject: [Pki-devel] [PATCH] 772 Updated instructions to customize TPS token lifecycle. In-Reply-To: <487925d6-6e1f-6cb4-387b-e0509ba99294@redhat.com> References: <487925d6-6e1f-6cb4-387b-e0509ba99294@redhat.com> Message-ID: <20160616004705.GL4744@dhcp-40-8.bne.redhat.com> On Wed, Jun 15, 2016 at 11:36:28AM -0500, Endi Sukma Dewata wrote: > The TPS's CS.cfg and token-states.properties have been updated > to include instructions to customize token state transitions and > labels. > > https://fedorahosted.org/pki/ticket/2300 > ACK From edewata at redhat.com Thu Jun 16 02:39:46 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 15 Jun 2016 21:39:46 -0500 Subject: [Pki-devel] [PATCH] 767 Fixed VLV usage in TPS token and activity services. In-Reply-To: <20160616002238.GJ4744@dhcp-40-8.bne.redhat.com> References: <8cd67dc8-a292-a465-afea-10ccd3c23948@redhat.com> <20160616002238.GJ4744@dhcp-40-8.bne.redhat.com> Message-ID: <9df4d295-e87f-2772-992b-b9e39f928617@redhat.com> On 6/15/2016 7:22 PM, Fraser Tweedale wrote: > Code changes look good. Might be nice to construct the > (Token|Activity)Collection objects inside the find* methods rather > than constructing it at call side and passing it in to be populated. > Just a nit, though. Thanks for the suggestion. I also considered that, but the reason I decided to create the response (i.e. collection) object outside the internal find*() methods is because the internal methods are just helper methods to populate certain aspects of the response object only (i.e. the entries and the total). Suppose they do create the response object, we probably would expect that the response object would be complete. However, notice that after the internal find*() invocations we're still adding links to the response object. Also they do not perform any parameter validation either, so these methods are not meant to be called directly by anything else. To clarify the distinction I've changed them to protected retrieve*WithVLV() and retrieve*WithoutVLV(). BTW, in the future we might want to change the latter method with simple paged results. > Searching/filtering continues to work as expected. > > ACK. Thanks! Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Jun 16 02:39:51 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 15 Jun 2016 21:39:51 -0500 Subject: [Pki-devel] [PATCH] 768 Added pki pkcs12-cert-mod command. In-Reply-To: <20160616003525.GK4744@dhcp-40-8.bne.redhat.com> References: <89778995-db70-9c85-208f-638a6cebdf12@redhat.com> <20160616003525.GK4744@dhcp-40-8.bne.redhat.com> Message-ID: <505c0a0c-358d-c50b-4790-9ca3aa55f456@redhat.com> On 6/15/2016 7:35 PM, Fraser Tweedale wrote: > Tested; does what it says on the tin. > ACK. Thanks! Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Jun 16 02:39:54 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 15 Jun 2016 21:39:54 -0500 Subject: [Pki-devel] [PATCH] 772 Updated instructions to customize TPS token lifecycle. In-Reply-To: <20160616004705.GL4744@dhcp-40-8.bne.redhat.com> References: <487925d6-6e1f-6cb4-387b-e0509ba99294@redhat.com> <20160616004705.GL4744@dhcp-40-8.bne.redhat.com> Message-ID: On 6/15/2016 7:47 PM, Fraser Tweedale wrote: > ACK Thanks! Pushed to master. -- Endi S. Dewata From ftweedal at redhat.com Thu Jun 16 03:45:34 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 16 Jun 2016 13:45:34 +1000 Subject: [Pki-devel] [PATCH] 767 Fixed VLV usage in TPS token and activity services. In-Reply-To: <9df4d295-e87f-2772-992b-b9e39f928617@redhat.com> References: <8cd67dc8-a292-a465-afea-10ccd3c23948@redhat.com> <20160616002238.GJ4744@dhcp-40-8.bne.redhat.com> <9df4d295-e87f-2772-992b-b9e39f928617@redhat.com> Message-ID: <20160616034533.GM4744@dhcp-40-8.bne.redhat.com> On Wed, Jun 15, 2016 at 09:39:46PM -0500, Endi Sukma Dewata wrote: > On 6/15/2016 7:22 PM, Fraser Tweedale wrote: > > Code changes look good. Might be nice to construct the > > (Token|Activity)Collection objects inside the find* methods rather > > than constructing it at call side and passing it in to be populated. > > Just a nit, though. > > Thanks for the suggestion. I also considered that, but the reason I decided > to create the response (i.e. collection) object outside the internal find*() > methods is because the internal methods are just helper methods to populate > certain aspects of the response object only (i.e. the entries and the > total). Suppose they do create the response object, we probably would expect > that the response object would be complete. However, notice that after the > internal find*() invocations we're still adding links to the response > object. Also they do not perform any parameter validation either, so these > methods are not meant to be called directly by anything else. To clarify the > distinction I've changed them to protected retrieve*WithVLV() and > retrieve*WithoutVLV(). BTW, in the future we might want to change the latter > method with simple paged results. > No worries; thanks for explaining. > > Searching/filtering continues to work as expected. > > > > ACK. > > Thanks! Pushed to master. > > -- > Endi S. Dewata From cfu at redhat.com Thu Jun 16 17:44:19 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 16 Jun 2016 10:44:19 -0700 Subject: [Pki-devel] [pki-devel][PATCH] 0071-UdnPwdDirAuth-authentication-plugin-instance-is-not-.patch In-Reply-To: <239521752.13620152.1465408709073.JavaMail.zimbra@redhat.com> References: <239521752.13620152.1465408709073.JavaMail.zimbra@redhat.com> Message-ID: <5762E573.90602@redhat.com> Looks good. If compiles, installs, and runs, ACK. Christina On 06/08/2016 10:58 AM, John Magne wrote: > UdnPwdDirAuth authentication plugin instance is not working. > > Ticket #1579 : UdnPwdDirAuth authentication plugin instance is not working. > > Since this class no longer works, we felt it best to just remove it from the server. > > This patch removes the references and files associated with this auth method,including the plugin > itself, so intrepid individuals will not be tempted to manually configure this auth method. > > QE has nicely decided to independently remove the tests associated with this plugin already. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Thu Jun 16 19:05:19 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 16 Jun 2016 14:05:19 -0500 Subject: [Pki-devel] [PATCH] 774 Added debugging log in ClientCertImportCLI. Message-ID: <7443c70e-4f81-0bfe-0a3d-962c61a36216@redhat.com> Pushed to master under one-liner/trivial rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0774-Added-debugging-log-in-ClientCertImportCLI.patch Type: text/x-patch Size: 1407 bytes Desc: not available URL: From jmagne at redhat.com Thu Jun 16 21:50:01 2016 From: jmagne at redhat.com (John Magne) Date: Thu, 16 Jun 2016 17:50:01 -0400 (EDT) Subject: [Pki-devel] Fix to ticket: [RFE] Enableocsp checking on KRA with CA's secure port shows self test failure In-Reply-To: <391708295.16496697.1466113724772.JavaMail.zimbra@redhat.com> Message-ID: <1236861724.16496986.1466113801849.JavaMail.zimbra@redhat.com> https://fedorahosted.org/pki/ticket/1507 Pushed to master: 92cb1fc3271f5928e9ad0db798b67a5761aefdb1 Under the trivial check in rule, which consisted of a modification to a comment. From cfu at redhat.com Thu Jun 16 22:50:48 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 16 Jun 2016 15:50:48 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0133-Ticket-2298-exclude-some-ldap-record-attributes-with.patch Message-ID: <57632D48.6060200@redhat.com> This is part 2 of: https://fedorahosted.org/pki/ticket/2298 [non-TMS] for key archival/recovery, not to record certain data in ldap and logs This patch allows one to exclude certain ldap attributes from the enrollment records for crmf requests (both CRMF, and CMC CRMF). The following are the highlights: * CRMF Manual approval profile is disabled: caDualCert.cfg - By default, if ca.excludedLDAPattrs.enabled is true, then this profile will not work, as the crmf requests are not written to ldap record for agents to act on * ca.excludedLDAPattrs.attrs can be used to configure the attribute list to be excluded * a new CRMF "auto approval" (directory based, needs to be setup) is provided * By default, the following fields are no longer written to the ldap record in case of CRMF: (note: the code deliberately use literal strings on purpose for the reason that the exact literal strings need to be spelled out in ca.excludedLDAPattrs.attrs if the admin chooses to override the default) "req_x509info", "publickey", "req_extensions", "cert_request", "req_archive_options", "req_key" * a sleepOneMinute() method is added for debugging purpose. It is not called in the final code, but is left there for future debugging purpose * code was fixed so that in KRA request will display subject name even though the x509info is missing from request * cmc requests did not have request type in records, so they had to be added for differentiation The following have been tested: * CRMF auto enroll * CRMF manual enroll/approval * CMC-CRMF enroll * both CA and KRA interla ldap are exampled for correct data exclusion Note: CRMF could potentially not include key archival option, however, I am not going to differentiate them at the moment. An earlier prototype I had built attempted to do that and the signing cert's record isn't excluded for attrs write while it's CRMF request is the same as that of its encryption cert counterpart within the same request. Due to this factor (multiple cert reqs with the same request blob), I am treating them the same for exclusion. thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0133-Ticket-2298-exclude-some-ldap-record-attributes-with.patch Type: text/x-patch Size: 29032 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 16 23:09:08 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 16 Jun 2016 18:09:08 -0500 Subject: [Pki-devel] [PATCH] 775-776 Fixed Java dependency Message-ID: <5b0f321d-4d4a-19c6-fed8-398d34095568@redhat.com> The code has been modified to use the JAVA_HOME path specified in the pki.conf. The spec file has been modified to depend specifically on OpenJDK 1.8.0 and to provide the default JAVA_HOME path for the pki.conf. Unused Tomcat 6 files have been removed. https://fedorahosted.org/pki/ticket/2363 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0775-Removed-unused-Tomcat-6-files.patch Type: text/x-patch Size: 12370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0776-Fixed-Java-dependency.patch Type: text/x-patch Size: 17303 bytes Desc: not available URL: From cfu at redhat.com Fri Jun 17 00:41:40 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 16 Jun 2016 17:41:40 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0133-Ticket-2298-exclude-some-ldap-record-attributes-with.patch In-Reply-To: <57632D48.6060200@redhat.com> References: <57632D48.6060200@redhat.com> Message-ID: <57634744.5020703@redhat.com> Thanks for Jack's sharp eye, i accidentally messed up the git wit one new profile. This new patch 1. fixed the git issue 2. change the CS.cfg config names to not include "ca" as they apply to kra too 3. Also after discussing with Jack, we decided to change the default of excludedLdapAttrs.enabled to false. thanks, Christina On 06/16/2016 03:50 PM, Christina Fu wrote: > This is part 2 of: > https://fedorahosted.org/pki/ticket/2298 [non-TMS] for key > archival/recovery, not to record certain data in ldap and logs > > This patch allows one to exclude certain ldap attributes from the > enrollment records for crmf requests > (both CRMF, and CMC CRMF). The following are the highlights: > * CRMF Manual approval profile is disabled: caDualCert.cfg > - By default, if ca.excludedLDAPattrs.enabled is true, then this > profile will not work, as the crmf requests > are not written to ldap record for agents to act on > * ca.excludedLDAPattrs.attrs can be used to configure the attribute > list to be excluded > * a new CRMF "auto approval" (directory based, needs to be setup) is > provided > * By default, the following fields are no longer written to the ldap > record in case of CRMF: > (note: the code deliberately use literal strings on purpose for the > reason that the exact literal strings need to be spelled out > in ca.excludedLDAPattrs.attrs if the admin chooses to override the > default) > "req_x509info", > "publickey", > "req_extensions", > "cert_request", > "req_archive_options", > "req_key" > * a sleepOneMinute() method is added for debugging purpose. It is not > called in the final code, but is left there for future debugging purpose > * code was fixed so that in KRA request will display subject name even > though the x509info is missing from request > * cmc requests did not have request type in records, so they had to be > added for differentiation > > The following have been tested: > * CRMF auto enroll > * CRMF manual enroll/approval > * CMC-CRMF enroll > * both CA and KRA interla ldap are exampled for correct data exclusion > > Note: CRMF could potentially not include key archival option, however, > I am not going to differentiate them at the moment. An earlier > prototype I had built attempted to do that and the signing cert's > record isn't excluded for attrs write while it's CRMF request is the > same as that of its encryption cert counterpart within the same > request. Due to this factor (multiple cert reqs with the same request > blob), I am treating them the same for exclusion. > > thanks, > Christina > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0137-Ticket-2298-exclude-some-ldap-record-attributes-with.patch Type: text/x-patch Size: 38629 bytes Desc: not available URL: From cfu at redhat.com Fri Jun 17 01:32:52 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 16 Jun 2016 18:32:52 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0133-Ticket-2298-exclude-some-ldap-record-attributes-with.patch In-Reply-To: <57634744.5020703@redhat.com> References: <57632D48.6060200@redhat.com> <57634744.5020703@redhat.com> Message-ID: <57635344.4090909@redhat.com> Received verbal ACK from Jack. Pushed to master: commit 51f34c3edb73a78b42468b756b89d07fc9ec7839 thanks, Christina On 06/16/2016 05:41 PM, Christina Fu wrote: > Thanks for Jack's sharp eye, i accidentally messed up the git wit one > new profile. This new patch > 1. fixed the git issue > 2. change the CS.cfg config names to not include "ca" as they apply to > kra too > 3. Also after discussing with Jack, we decided to change the default > of excludedLdapAttrs.enabled to false. > > thanks, > Christina > > On 06/16/2016 03:50 PM, Christina Fu wrote: >> This is part 2 of: >> https://fedorahosted.org/pki/ticket/2298 [non-TMS] for key >> archival/recovery, not to record certain data in ldap and logs >> >> This patch allows one to exclude certain ldap attributes from the >> enrollment records for crmf requests >> (both CRMF, and CMC CRMF). The following are the highlights: >> * CRMF Manual approval profile is disabled: caDualCert.cfg >> - By default, if ca.excludedLDAPattrs.enabled is true, then this >> profile will not work, as the crmf requests >> are not written to ldap record for agents to act on >> * ca.excludedLDAPattrs.attrs can be used to configure the attribute >> list to be excluded >> * a new CRMF "auto approval" (directory based, needs to be setup) is >> provided >> * By default, the following fields are no longer written to the ldap >> record in case of CRMF: >> (note: the code deliberately use literal strings on purpose for the >> reason that the exact literal strings need to be spelled out >> in ca.excludedLDAPattrs.attrs if the admin chooses to override the >> default) >> "req_x509info", >> "publickey", >> "req_extensions", >> "cert_request", >> "req_archive_options", >> "req_key" >> * a sleepOneMinute() method is added for debugging purpose. It is >> not called in the final code, but is left there for future debugging >> purpose >> * code was fixed so that in KRA request will display subject name >> even though the x509info is missing from request >> * cmc requests did not have request type in records, so they had to >> be added for differentiation >> >> The following have been tested: >> * CRMF auto enroll >> * CRMF manual enroll/approval >> * CMC-CRMF enroll >> * both CA and KRA interla ldap are exampled for correct data exclusion >> >> Note: CRMF could potentially not include key archival option, >> however, I am not going to differentiate them at the moment. An >> earlier prototype I had built attempted to do that and the signing >> cert's record isn't excluded for attrs write while it's CRMF request >> is the same as that of its encryption cert counterpart within the >> same request. Due to this factor (multiple cert reqs with the same >> request blob), I am treating them the same for exclusion. >> >> thanks, >> Christina >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Fri Jun 17 05:54:24 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Jun 2016 00:54:24 -0500 Subject: [Pki-devel] [PATCH] 775-776 Fixed Java dependency In-Reply-To: <5b0f321d-4d4a-19c6-fed8-398d34095568@redhat.com> References: <5b0f321d-4d4a-19c6-fed8-398d34095568@redhat.com> Message-ID: On 06/16/2016 06:09 PM, Endi Sukma Dewata wrote: > The code has been modified to use the JAVA_HOME path specified in > the pki.conf. > > The spec file has been modified to depend specifically on OpenJDK > 1.8.0 and to provide the default JAVA_HOME path for the pki.conf. > > Unused Tomcat 6 files have been removed. > > https://fedorahosted.org/pki/ticket/2363 > New patch #776-1 for a minor cleanup. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0776-1-Fixed-Java-dependency.patch Type: text/x-patch Size: 17276 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 17 05:54:35 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Jun 2016 00:54:35 -0500 Subject: [Pki-devel] [PATCH] 777 Added upgrade script to fix JAVA_HOME. Message-ID: <19021315-6f8c-ec16-62c9-ec364e3b37a1@redhat.com> https://fedorahosted.org/pki/ticket/2363 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0777-Added-upgrade-script-to-fix-JAVA_HOME.patch Type: text/x-patch Size: 6194 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jun 17 07:34:27 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 17 Jun 2016 17:34:27 +1000 Subject: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> Message-ID: <20160617073427.GR4744@dhcp-40-8.bne.redhat.com> 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. It could be an error to run the command on other than the renewal master. 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 From edewata at redhat.com Fri Jun 17 18:40:44 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Jun 2016 13:40:44 -0500 Subject: [Pki-devel] [PATCH] 775-776 Fixed Java dependency In-Reply-To: References: <5b0f321d-4d4a-19c6-fed8-398d34095568@redhat.com> Message-ID: <7ac774c4-ba62-028d-74a7-c8990a04f267@redhat.com> On 6/17/2016 12:54 AM, Endi Sukma Dewata wrote: > On 06/16/2016 06:09 PM, Endi Sukma Dewata wrote: >> The code has been modified to use the JAVA_HOME path specified in >> the pki.conf. >> >> The spec file has been modified to depend specifically on OpenJDK >> 1.8.0 and to provide the default JAVA_HOME path for the pki.conf. >> >> Unused Tomcat 6 files have been removed. >> >> https://fedorahosted.org/pki/ticket/2363 >> > > New patch #776-1 for a minor cleanup. ACKed by jmagne, and ftweedal also helped with the review. Thanks! Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Jun 17 18:41:00 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Jun 2016 13:41:00 -0500 Subject: [Pki-devel] [PATCH] 777 Added upgrade script to fix JAVA_HOME. In-Reply-To: <19021315-6f8c-ec16-62c9-ec364e3b37a1@redhat.com> References: <19021315-6f8c-ec16-62c9-ec364e3b37a1@redhat.com> Message-ID: <278e8230-1528-cd59-a87b-bebcb938f566@redhat.com> On 6/17/2016 12:54 AM, Endi Sukma Dewata wrote: > https://fedorahosted.org/pki/ticket/2363 ACKed by jmagne, and ftweedal also helped with the review. Thanks! Pushed to master. -- Endi S. Dewata From jmagne at redhat.com Fri Jun 17 21:34:55 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 17 Jun 2016 17:34:55 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0072-Revocation-failure-causes-AUDIT_PRIVATE_KEY_ARCHIVE_.patch In-Reply-To: <1629734899.15352521.1465945669018.JavaMail.zimbra@redhat.com> References: <1629734899.15352521.1465945669018.JavaMail.zimbra@redhat.com> Message-ID: <389458928.16954251.1466199295102.JavaMail.zimbra@redhat.com> ACK'd by cfu: Pushed to master, closing ticket #2340 ----- Original Message ----- From: "John Magne" To: "pki-devel" Sent: Tuesday, June 14, 2016 4:07:49 PM Subject: [pki-devel][PATCH] 0072-Revocation-failure-causes-AUDIT_PRIVATE_KEY_ARCHIVE_.patch Revocation failure causes AUDIT_PRIVATE_KEY_ARCHIVE_REQUEST The fix here is to make sure no archive related audits get issued for doing things other than key archivals. Other operations such as revoking and unrevoking cert in the code path laready have audit logs issued separately for success or failure. Ticket #2340. From jmagne at redhat.com Fri Jun 17 21:44:46 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 17 Jun 2016 17:44:46 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0070-Fix-coverity-warnings-for-tkstool.patch In-Reply-To: <1997519853.12953347.1465256383335.JavaMail.zimbra@redhat.com> References: <1997519853.12953347.1465256383335.JavaMail.zimbra@redhat.com> Message-ID: <1095494845.16956265.1466199886766.JavaMail.zimbra@redhat.com> ACK'ed by mharmsen, pushed to master: Closing ticket #1199 ----- Original Message ----- From: "John Magne" To: "pki-devel" Sent: Monday, June 6, 2016 4:39:43 PM Subject: [pki-devel][PATCH] 0070-Fix-coverity-warnings-for-tkstool.patch Fix attached. From cfu at redhat.com Fri Jun 17 21:54:33 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 17 Jun 2016 14:54:33 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch Message-ID: <57647199.2010809@redhat.com> This is the last patch for ttps://fedorahosted.org/pki/ticket/2298 [non-TMS] for key archival/recovery, not to record certain data in ldap and logs It mainly trims down the debug log and rids off CRMF requests. it also gets rid of some excessive debugging in exercised areas. In the last patch, CS.cfg is introduced a new profile, which accidentally got copied in a hard coded path, which is fixed too. thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch Type: text/x-patch Size: 22718 bytes Desc: not available URL: From jmagne at redhat.com Fri Jun 17 22:06:31 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 17 Jun 2016 18:06:31 -0400 (EDT) Subject: [Pki-devel] [PATCH] pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch In-Reply-To: <57647199.2010809@redhat.com> References: <57647199.2010809@redhat.com> Message-ID: <6975971.16958227.1466201191748.JavaMail.zimbra@redhat.com> If tested to work and no offending logs remain: ACK ----- Original Message ----- From: "Christina Fu" To: "pki-devel" Sent: Friday, June 17, 2016 2:54:33 PM Subject: [Pki-devel] [PATCH] pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch This is the last patch for ttps://fedorahosted.org/pki/ticket/2298 [non-TMS] for key archival/recovery, not to record certain data in ldap and logs It mainly trims down the debug log and rids off CRMF requests. it also gets rid of some excessive debugging in exercised areas. In the last patch, CS.cfg is introduced a new profile, which accidentally got copied in a hard coded path, which is fixed too. thanks, Christina _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Fri Jun 17 22:10:10 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 17 Jun 2016 15:10:10 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch In-Reply-To: <6975971.16958227.1466201191748.JavaMail.zimbra@redhat.com> References: <57647199.2010809@redhat.com> <6975971.16958227.1466201191748.JavaMail.zimbra@redhat.com> Message-ID: <57647542.8030602@redhat.com> pushed to master: commit 62d8908d91e74320db647b939c0d9900c09d0608 thanks, Christina On 06/17/2016 03:06 PM, John Magne wrote: > If tested to work and no offending logs remain: > > ACK > > ----- Original Message ----- > From: "Christina Fu" > To: "pki-devel" > Sent: Friday, June 17, 2016 2:54:33 PM > Subject: [Pki-devel] [PATCH] pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch > > This is the last patch for > ttps://fedorahosted.org/pki/ticket/2298 [non-TMS] for key > archival/recovery, not to record certain data in ldap and logs > > It mainly trims down the debug log and rids off CRMF requests. it also > gets rid of some excessive debugging in exercised areas. > In the last patch, CS.cfg is introduced a new profile, which > accidentally got copied in a hard coded path, which is fixed too. > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Fri Jun 17 23:48:31 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 17 Jun 2016 16:48:31 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch Message-ID: <57648C4F.6000607@redhat.com> This patch adds support for SHA384withRSA signing algorithm. It addresses ticket: https://fedorahosted.org/pki/ticket/2346 java.security.NoSuchAlgorithmException: no such algorithm: OID.1.2.840.113549.1.1.12 for provider Mozilla-JSS when signing a CSR using SHA384withRSA Tested to work with 1. the CSR provided by bug reporter in ticket against caServerCert enrollment profile 2. few selected profiles sample result: Signature Algorithm: SHA384withRSA - 1.2.840.113549.1.1.12 thanks, Christina From cfu at redhat.com Sat Jun 18 00:08:17 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 17 Jun 2016 17:08:17 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch In-Reply-To: <57648C4F.6000607@redhat.com> References: <57648C4F.6000607@redhat.com> Message-ID: <576490F1.3080309@redhat.com> forgot to attach patch... here you go. On 06/17/2016 04:48 PM, Christina Fu wrote: > This patch adds support for SHA384withRSA signing algorithm. > It addresses ticket: https://fedorahosted.org/pki/ticket/2346 > java.security.NoSuchAlgorithmException: no such algorithm: > OID.1.2.840.113549.1.1.12 for provider Mozilla-JSS when signing a CSR > using SHA384withRSA > > Tested to work with > 1. the CSR provided by bug reporter in ticket against caServerCert > enrollment profile > 2. few selected profiles > > sample result: > > Signature Algorithm: SHA384withRSA - 1.2.840.113549.1.1.12 > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch Type: text/x-patch Size: 64313 bytes Desc: not available URL: From jmagne at redhat.com Sat Jun 18 00:31:47 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 17 Jun 2016 20:31:47 -0400 (EDT) Subject: [Pki-devel] [PATCH] pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch In-Reply-To: <576490F1.3080309@redhat.com> References: <57648C4F.6000607@redhat.com> <576490F1.3080309@redhat.com> Message-ID: <928339996.16965394.1466209907849.JavaMail.zimbra@redhat.com> Looked over. Pretty straightforward additions. As long as the stated successful test worked. ACK ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Friday, June 17, 2016 5:08:17 PM Subject: Re: [Pki-devel] [PATCH] pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch forgot to attach patch... here you go. On 06/17/2016 04:48 PM, Christina Fu wrote: > This patch adds support for SHA384withRSA signing algorithm. > It addresses ticket: https://fedorahosted.org/pki/ticket/2346 > java.security.NoSuchAlgorithmException: no such algorithm: > OID.1.2.840.113549.1.1.12 for provider Mozilla-JSS when signing a CSR > using SHA384withRSA > > Tested to work with > 1. the CSR provided by bug reporter in ticket against caServerCert > enrollment profile > 2. few selected profiles > > sample result: > > Signature Algorithm: SHA384withRSA - 1.2.840.113549.1.1.12 > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Sat Jun 18 00:36:54 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 17 Jun 2016 17:36:54 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch In-Reply-To: <928339996.16965394.1466209907849.JavaMail.zimbra@redhat.com> References: <57648C4F.6000607@redhat.com> <576490F1.3080309@redhat.com> <928339996.16965394.1466209907849.JavaMail.zimbra@redhat.com> Message-ID: <576497A6.40606@redhat.com> pushed to master: commit 158bb22a87832ff2be07ac4b75c8f2927caefd55 thanks, Christina On 06/17/2016 05:31 PM, John Magne wrote: > Looked over. > > Pretty straightforward additions. > As long as the stated successful test worked. > > ACK > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Friday, June 17, 2016 5:08:17 PM > Subject: Re: [Pki-devel] [PATCH] pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch > > forgot to attach patch... here you go. > > On 06/17/2016 04:48 PM, Christina Fu wrote: >> This patch adds support for SHA384withRSA signing algorithm. >> It addresses ticket: https://fedorahosted.org/pki/ticket/2346 >> java.security.NoSuchAlgorithmException: no such algorithm: >> OID.1.2.840.113549.1.1.12 for provider Mozilla-JSS when signing a CSR >> using SHA384withRSA >> >> Tested to work with >> 1. the CSR provided by bug reporter in ticket against caServerCert >> enrollment profile >> 2. few selected profiles >> >> sample result: >> >> Signature Algorithm: SHA384withRSA - 1.2.840.113549.1.1.12 >> >> thanks, >> Christina >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ftweedal at redhat.com Sat Jun 18 00:38:03 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 18 Jun 2016 10:38:03 +1000 Subject: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> <20160617073427.GR4744@dhcp-40-8.bne.redhat.com> Message-ID: <20160618003803.GB4200@dhcp-40-8.bne.redhat.com> 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. 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. > > > > 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 From ftweedal at redhat.com Tue Jun 21 05:55:00 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 21 Jun 2016 15:55:00 +1000 Subject: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: <9406ecb2-8727-370e-6a7a-d0f22b3d7499@redhat.com> References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> <20160617073427.GR4744@dhcp-40-8.bne.redhat.com> <20160618003803.GB4200@dhcp-40-8.bne.redhat.com> <9406ecb2-8727-370e-6a7a-d0f22b3d7499@redhat.com> Message-ID: <20160621055500.GC4200@dhcp-40-8.bne.redhat.com> On Tue, Jun 21, 2016 at 07:29:22AM +0200, Jan Cholasta wrote: > 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. > I'll need to check a few things, because the current renewal hook updates certificate values in CS.cfg for the main CA signing and subsystem certs. Therefore, the patches (I'm about to send them) preserve existing behaviour for the main CA cert. It will be easy to change to the new mechanism for the main CA cert once I make sure that everything will work. Cheers, Fraser > > > > > > > > > > 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 > > > -- > Jan Cholasta From akahat at redhat.com Tue Jun 21 07:23:18 2016 From: akahat at redhat.com (Amol Kahat) Date: Tue, 21 Jun 2016 12:53:18 +0530 Subject: [Pki-devel] Fixes pki-server subsystem --help options. Message-ID: <5768EB66.6020702@redhat.com> Hi, Please review this patch. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1340718 Thanks Amol K. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixes-pki-server-subsystem-help-options.patch Type: text/x-patch Size: 9349 bytes Desc: not available URL: From akahat at redhat.com Tue Jun 21 07:55:20 2016 From: akahat at redhat.com (Amol Kahat) Date: Tue, 21 Jun 2016 13:25:20 +0530 Subject: [Pki-devel] Invalid instance exception fix. Message-ID: <5768F2E8.2050504@redhat.com> Hi, Please review this patch. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1348433 Thanks Amol K. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixes-Invalid-instance-exception-issue.patch Type: text/x-patch Size: 4387 bytes Desc: not available URL: From akahat at redhat.com Tue Jun 21 08:19:00 2016 From: akahat at redhat.com (Amol Kahat) Date: Tue, 21 Jun 2016 13:49:00 +0530 Subject: [Pki-devel] Fixes exception while invalid module. Message-ID: <5768F874.6020107@redhat.com> Hi, Please review this patch. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1348446 Thanks Amol K -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixes-https-bugzilla.redhat.com-show_bug.cgi-id-1348.patch Type: text/x-patch Size: 1127 bytes Desc: not available URL: From edewata at redhat.com Tue Jun 21 19:03:57 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 21 Jun 2016 14:03:57 -0500 Subject: [Pki-devel] [PATCH] 778 Fixed KRA cloning issue. Message-ID: <8fc52c84-c6dc-309c-6aac-cb3f8a6f3bd6@redhat.com> The pki pkcs12-import CLI has been modified not to import certificates that already exist in the NSS database unless specifically requested with the --overwrite parameter. This will avoid changing the trust flags of the CA signing certificate during KRA cloning. The some other classes have been modified to provide better debugging information. https://fedorahosted.org/pki/ticket/2374 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0778-Fixed-KRA-cloning-issue.patch Type: text/x-patch Size: 18808 bytes Desc: not available URL: From mharmsen at redhat.com Wed Jun 22 01:45:47 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 21 Jun 2016 19:45:47 -0600 Subject: [Pki-devel] Karma Request for Dogtag 10.3.3 on Fedora 24 Message-ID: <5769EDCB.7040800@redhat.com> The following candidate builds of Dogtag 10.3.3 for Fedora 24 consist of the following: * dogtag-pki-10.3.3-1.fc24 * dogtag-pki-theme-10.3.3-1.fc24 * pki-core-10.3.3-1.fc24 * pki-console-10.3.3-1.fc24 Please provide Karma for these builds in Bodhi located at: * https://bodhi.fedoraproject.org/updates/FEDORA-2016-f79d05d2c4 dogtag-pki-10.3.3-1.fc24 * https://bodhi.fedoraproject.org/updates/FEDORA-2016-a4e6c2b81f dogtag-pki-theme-10.3.3-1.fc24 * https://bodhi.fedoraproject.org/updates/FEDORA-2016-bc6bc7b4dc pki-core-10.3.3-1.fc24 * https://bodhi.fedoraproject.org/updates/FEDORA-2016-6c3e450b6b pki-console-10.3.3-1.fc24 Additionally, the following builds have been provided for Fedora 25 (rawhide): * dogtag-pki-10.3.3-1.fc25 * dogtag-pki-theme-10.3.3-1.fc25 Unfortunately, Dogtag 10.3.3 is currently broken on Fedora 24 (rawhide) due to the following issue: * PKI TRAC Ticket #2373 - Fedora 25: RestEasy 3.0.6 ==> 3.0.17 breaks pki-core which prohibits building: * pki-core-10.3.3-1.fc25 * pki-console-10.3.3-1.fc25 (which depends on pki-java-base-10.3.3-1.fc25 that is a part of the pki-core-10.3.3-1.fc25 package) Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Wed Jun 22 06:13:45 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 22 Jun 2016 00:13:45 -0600 Subject: [Pki-devel] Updated External EPEL CentOS 7 COPR builds are now available . . . Message-ID: <576A2C99.60409@redhat.com> An updated external EPEL CentOS 7 COPR repo is now available which contains Dogtag 10.3.3 builds: * https://copr.fedorainfracloud.org/coprs/g/pki/10.3.3/repo/epel-7/group_pki-10.3.3-epel-7.repo [group_pki-10.3.3] name=Copr repo for 10.3.3 owned by @pki baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/epel-7-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.3/pubkey.gpg enabled=1 enabled_metadata=1 -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From akahat at redhat.com Wed Jun 22 08:13:04 2016 From: akahat at redhat.com (Amol Kahat) Date: Wed, 22 Jun 2016 13:43:04 +0530 Subject: [Pki-devel] [PATCH] Added --token-password in pki-server instance-externalcert-add / del command. Message-ID: <576A4890.6010503@redhat.com> Hi, Please review this patch. Fixes : https://bugzilla.redhat.com/show_bug.cgi?id=1348531 Thanks Amol K -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-token-password-option-in.patch Type: text/x-patch Size: 7570 bytes Desc: not available URL: From ftweedal at redhat.com Wed Jun 22 09:53:16 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 22 Jun 2016 19:53:16 +1000 Subject: [Pki-devel] [PATCH] 0124 Add profiles container to LDAP if missing Message-ID: <20160622095315.GI4200@dhcp-40-8.bne.redhat.com> The attached patch fixes https://fedorahosted.org/pki/ticket/2285. See commit message and bz1323400[1] for full history and details. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1323400 The fix should be merged to master and DOGTAG_10_2_BRANCH, and a new 10.2.x release cut for f23. I have an f23 COPR build containing the fix for anyone wishing to test: https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/packages/ Huge props to Adam Williamson for doing a lot of legwork in tracking down the cause of this issue. Thanks, Fraser -------------- next part -------------- From 4cbaf297690bf95fffc864cb109bdd6ae49c9dc3 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 22 Jun 2016 13:34:01 +1000 Subject: [PATCH] Add profiles container to LDAP if missing CMS startup was changed a while back to wait for LDAPProfileSubsystem initialisation, while LDAPProfileSubsystem initialisation waits for all known profiles to be loaded by the LDAP persistent search thread. If the ou=certificateProfiles container object does not exist, startup hangs. This can cause a race condition in FreeIPA upgrade. FreeIPA switches the Dogtag instance to the LDAPProfileSubsystem and restarts it. The restart fails because the container object does not get added until after the restart. Update LDAPProfileSubsystem to add the container object itself, if it is missing, before commencing the persistent search. Fixes: https://fedorahosted.org/pki/ticket/2285 --- .../cmscore/profile/LDAPProfileSubsystem.java | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java index 28b34cda889cc6c2eba4fc3392863df36717fa14..6dea1a0d88beaefeea489ea58ad9ad13d2da8bd7 100644 --- a/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java +++ b/base/server/cmscore/src/com/netscape/cmscore/profile/LDAPProfileSubsystem.java @@ -27,6 +27,7 @@ import java.util.TreeSet; import java.util.concurrent.CountDownLatch; import netscape.ldap.LDAPAttribute; +import netscape.ldap.LDAPAttributeSet; import netscape.ldap.LDAPConnection; import netscape.ldap.LDAPDN; import netscape.ldap.LDAPEntry; @@ -400,6 +401,23 @@ public class LDAPProfileSubsystem initialLoadDone.countDown(); } + private void ensureProfilesOU(LDAPConnection conn) throws LDAPException { + try { + conn.search(dn, LDAPConnection.SCOPE_BASE, "(objectclass=*)", null, false); + } catch (LDAPException e) { + if (e.getLDAPResultCode() == LDAPException.NO_SUCH_OBJECT) { + CMS.debug("Adding LDAP certificate profiles container"); + LDAPAttribute[] attrs = { + new LDAPAttribute("objectClass", "organizationalUnit"), + new LDAPAttribute("ou", "certificateProfiles") + }; + LDAPAttributeSet attrSet = new LDAPAttributeSet(attrs); + LDAPEntry entry = new LDAPEntry(dn, attrSet); + conn.add(entry); + } + } + } + public void run() { int op = LDAPPersistSearchControl.ADD | LDAPPersistSearchControl.MODIFY @@ -416,6 +434,7 @@ public class LDAPProfileSubsystem forgetAllProfiles(); try { conn = dbFactory.getConn(); + ensureProfilesOU(conn); LDAPSearchConstraints cons = conn.getSearchConstraints(); cons.setServerControls(persistCtrl); cons.setBatchSize(1); -- 2.5.5 From jmagne at redhat.com Thu Jun 23 22:33:44 2016 From: jmagne at redhat.com (John Magne) Date: Thu, 23 Jun 2016 18:33:44 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0073-Separated-TPS-does-not-automatically-receive-shared-.patch In-Reply-To: <1409340277.1798746.1466720992575.JavaMail.zimbra@redhat.com> Message-ID: <1551493855.1800384.1466721224768.JavaMail.zimbra@redhat.com> [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. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0073-Separated-TPS-does-not-automatically-receive-shared-.patch Type: text/x-patch Size: 68155 bytes Desc: not available URL: From jcholast at redhat.com Fri Jun 17 13:21:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 17 Jun 2016 15:21:07 +0200 Subject: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: <20160617073427.GR4744@dhcp-40-8.bne.redhat.com> References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> <20160617073427.GR4744@dhcp-40-8.bne.redhat.com> Message-ID: 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 From jcholast at redhat.com Tue Jun 21 05:29:22 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 21 Jun 2016 07:29:22 +0200 Subject: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: <20160618003803.GB4200@dhcp-40-8.bne.redhat.com> References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> <20160617073427.GR4744@dhcp-40-8.bne.redhat.com> <20160618003803.GB4200@dhcp-40-8.bne.redhat.com> Message-ID: <9406ecb2-8727-370e-6a7a-d0f22b3d7499@redhat.com> 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 -- Jan Cholasta From jmagne at redhat.com Fri Jun 24 18:08:15 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 24 Jun 2016 14:08:15 -0400 (EDT) Subject: [Pki-devel] [pki-devel] [PATCH] 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch In-Reply-To: <1798239609.2156935.1466791672248.JavaMail.zimbra@redhat.com> Message-ID: <1043889111.2156974.1466791695663.JavaMail.zimbra@redhat.com> Add ability to disallow TPS to enroll a single user on multiple tokens. This patch will install a check during the early portion of the enrollment process check a configurable policy whether or not a user should be allowed to have more that one active token. This check will take place only for brand new tokens not seen before. The check will prevent the enrollment to proceed and will exit before the system has a chance to add this new token to the TPS tokendb. The behavior will be configurable for the the external reg and not external reg scenarios as follows: op.enroll.nonExternalReg.allowMultiActiveTokensUser=false op.enroll.externalReg.allowMultiActiveTokensUser=false -------------- next part -------------- A non-text attachment was scrubbed... Name: 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch Type: text/x-patch Size: 7180 bytes Desc: not available URL: From mharmsen at redhat.com Fri Jun 24 20:45:54 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 24 Jun 2016 14:45:54 -0600 Subject: [Pki-devel] [PATCH] Normalize default softokn name Message-ID: <576D9C02.2090700@redhat.com> Please review the attached patch which addresses the following ticket: * PKI TRAC Ticket #2311 - When pki_token_name=Internal, consider normalizing it to "internal" A brief smoke test of this patch worked successfully. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20160624-Normalize-default-softokn-name.patch Type: text/x-patch Size: 1792 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 24 22:45:30 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 24 Jun 2016 17:45:30 -0500 Subject: [Pki-devel] [PATCH] 779 Fixed problem reading HSM password from password file. Message-ID: A new method get_token_password() has been added into PKIInstance Python class in order to read the token password correctly from password.conf. If the token is an internal token, it will read the 'internal' password. If it is an HSM it will read the password for 'hardware-'. The codes that call the get_password() to get token password have been modified to use get_token_password() instead. https://fedorahosted.org/pki/ticket/2384 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0779-Fixed-problem-reading-HSM-password-from-password-fil.patch Type: text/x-patch Size: 8110 bytes Desc: not available URL: From jmagne at redhat.com Sat Jun 25 00:23:25 2016 From: jmagne at redhat.com (John Magne) Date: Fri, 24 Jun 2016 20:23:25 -0400 (EDT) Subject: [Pki-devel] [pki-devel][PATCH] 0075-Generting-Symmetric-key-fails-with-key-generate-when.patch In-Reply-To: <1890343232.2205816.1466814159437.JavaMail.zimbra@redhat.com> Message-ID: <926945076.2205852.1466814205230.JavaMail.zimbra@redhat.com> Generting Symmetric key fails with key-generate when --usages verify is passed Ticket #1114 Minor adjustment to the man page for the key management commands to say which usages are appropriate for sym keys and those appropriate for asym keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0075-Generting-Symmetric-key-fails-with-key-generate-when.patch Type: text/x-patch Size: 1451 bytes Desc: not available URL: From cfu at redhat.com Sat Jun 25 01:46:30 2016 From: cfu at redhat.com (Christina Fu) Date: Fri, 24 Jun 2016 18:46:30 -0700 Subject: [Pki-devel] [PATCH] 779 Fixed problem reading HSM password from password file. In-Reply-To: References: Message-ID: <576DE276.8090300@redhat.com> Looks like might do it. If tested to work (borrow a vm from QE if you don't have one), ack. Christina On 06/24/2016 03:45 PM, Endi Sukma Dewata wrote: > A new method get_token_password() has been added into PKIInstance > Python class in order to read the token password correctly from > password.conf. If the token is an internal token, it will read the > 'internal' password. If it is an HSM it will read the password for > 'hardware-'. > > The codes that call the get_password() to get token password have > been modified to use get_token_password() instead. > > https://fedorahosted.org/pki/ticket/2384 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Jun 27 06:38:10 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 27 Jun 2016 16:38:10 +1000 Subject: [Pki-devel] [PATCH] 0125 AuthInfoAccess: use default OCSP URI if configured Message-ID: <20160627063810.GT4200@dhcp-40-8.bne.redhat.com> Attached patch fixes https://fedorahosted.org/pki/ticket/2387 (wanted for 10.3.4). Thanks, Fraser -------------- next part -------------- From 53064626ec30f2d15d6e8a62ab159e3b541f2971 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 27 Jun 2016 15:04:44 +1000 Subject: [PATCH] AuthInfoAccess: use default OCSP URI if configured The AuthInfoAccessExtDefault profile component constructs an OCSP URI based on the current host and port, if no URI is explicitly configured in the profile. Update the component to look in CS.cfg for the "ca.defaultOcspUri" config, and use its value if present. If not present, the old behaviour prevails. Also add the 'pki_default_ocsp_uri' pkispawn config to add the config during instance creation, so that the value will be used for the CA and system certificates. Fixes: https://fedorahosted.org/pki/ticket/2387 --- .../src/com/netscape/cms/profile/def/AuthInfoAccessExtDefault.java | 5 +++-- base/server/python/pki/server/deployment/scriptlets/configuration.py | 5 +++++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/base/server/cms/src/com/netscape/cms/profile/def/AuthInfoAccessExtDefault.java b/base/server/cms/src/com/netscape/cms/profile/def/AuthInfoAccessExtDefault.java index 36818a90753b75f958cca4dd4c93f18629b93411..1190f28a326c9243b6791b7eeb7a01ad77aa74b2 100644 --- a/base/server/cms/src/com/netscape/cms/profile/def/AuthInfoAccessExtDefault.java +++ b/base/server/cms/src/com/netscape/cms/profile/def/AuthInfoAccessExtDefault.java @@ -430,9 +430,10 @@ public class AuthInfoAccessExtDefault extends EnrollExtDefault { if (method.equals("1.3.6.1.5.5.7.48.1")) { String hostname = CMS.getEENonSSLHost(); String port = CMS.getEENonSSLPort(); + String uri = ""; if (hostname != null && port != null) - // location = "http://"+hostname+":"+port+"/ocsp/ee/ocsp"; - location = "http://" + hostname + ":" + port + "/ca/ocsp"; + uri = "http://" + hostname + ":" + port + "/ca/ocsp"; + location = CMS.getConfigStore().getString("ca.defaultOcspUri", uri); } } diff --git a/base/server/python/pki/server/deployment/scriptlets/configuration.py b/base/server/python/pki/server/deployment/scriptlets/configuration.py index b8505dd9b7d59a527f21c07f2fb55bde1f46eafa..64ee4e5f6f5cbc920c7ac5a27ab995d7155cf1cc 100644 --- a/base/server/python/pki/server/deployment/scriptlets/configuration.py +++ b/base/server/python/pki/server/deployment/scriptlets/configuration.py @@ -87,6 +87,11 @@ class PkiScriptlet(pkiscriptlet.AbstractBasePkiScriptlet): subsystem = instance.get_subsystem( deployer.mdict['pki_subsystem'].lower()) + ocsp_uri = deployer.mdict.get('pki_default_ocsp_uri') + if ocsp_uri: + subsystem.config['ca.defaultOcspUri'] = ocsp_uri + subsystem.save() + token = deployer.mdict['pki_token_name'] nssdb = instance.open_nssdb(token) -- 2.5.5 From cfu at redhat.com Mon Jun 27 21:25:33 2016 From: cfu at redhat.com (Christina Fu) Date: Mon, 27 Jun 2016 14:25:33 -0700 Subject: [Pki-devel] [pki-devel] [PATCH] 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch In-Reply-To: <1043889111.2156974.1466791695663.JavaMail.zimbra@redhat.com> References: <1043889111.2156974.1466791695663.JavaMail.zimbra@redhat.com> Message-ID: <577199CD.8040706@redhat.com> Just a few minor ones. * configuration parameters referencing token existence in tokendb should use names begin with "tokendb". e.g. tokendb.allowMultiActiveTokensPerUser.externalReg=false tokendb.allowMultiActiveTokensPerUser.nonExternalReg=false * boolean allowMultiCerts -- I think the name is misleading. how about alowMultiTokens * existing calls to tps.tdb.tdbHasActiveToken() need to be decided: e.g. 1. TPSEnrollProcessor.java search for tdbHasActiveToken (first occurrence) , you will find that it is called with "TODO:" comment. I believe that whole try/catch with the tps.tdb.tdbHasActiveToken(userid); call can be removed since you already call that earlier in your patch 2. TPSEnrollProcessor.java, the 2nd occurrence is when the enrolling token is suspended. You need to look into what it is doing at the point and whether that check can also be eliminated. thanks, Christina On 06/24/2016 11:08 AM, John Magne wrote: > Add ability to disallow TPS to enroll a single user on multiple tokens. > > This patch will install a check during the early portion of the enrollment > process check a configurable policy whether or not a user should be allowed > to have more that one active token. > > This check will take place only for brand new tokens not seen before. > The check will prevent the enrollment to proceed and will exit before the system > has a chance to add this new token to the TPS tokendb. > > The behavior will be configurable for the the external reg and not external reg scenarios > as follows: > > op.enroll.nonExternalReg.allowMultiActiveTokensUser=false > op.enroll.externalReg.allowMultiActiveTokensUser=false > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Jun 28 00:04:19 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 27 Jun 2016 19:04:19 -0500 Subject: [Pki-devel] [PATCH] 779 Fixed problem reading HSM password from password file. In-Reply-To: <576DE276.8090300@redhat.com> References: <576DE276.8090300@redhat.com> Message-ID: <2d4a40e7-bbd8-b5cc-fc75-990b44cee70b@redhat.com> On 6/24/2016 8:46 PM, Christina Fu wrote: > Looks like might do it. If tested to work (borrow a vm from QE if you > don't have one), ack. Thanks! I've tested it with QE's machine with HSM. Pushed to master. -- Endi S. Dewata From ftweedal at redhat.com Tue Jun 28 02:52:03 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 28 Jun 2016 12:52:03 +1000 Subject: [Pki-devel] [PATCH] 0126 Respond 400 if lightweight CA cert issuance fails Message-ID: <20160628025203.GW4200@dhcp-40-8.bne.redhat.com> The attached patch fixes https://fedorahosted.org/pki/ticket/2388. Wanted for 10.3.4. Thanks, Fraser -------------- next part -------------- From 3ad777d8009f025f1aac1159910dd0a4d327bd13 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Sat, 25 Jun 2016 00:14:11 +0200 Subject: [PATCH] Respond 400 if lightweight CA cert issuance fails If certificate issuance fails during lightweight CA creation (e.g. due to a profile constraint violation such as Subject DN not matching pattern) the API responds with status 500. Raise BadRequestDataException if cert issuance fails in a way that indicates bad or invalid CSR data, and catch it to respond with status 400. Fixes: https://fedorahosted.org/pki/ticket/2388 --- base/ca/src/com/netscape/ca/CertificateAuthority.java | 18 +++++++++++++++--- .../org/dogtagpki/server/ca/rest/AuthorityService.java | 3 ++- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java index e501380c8dd6d2d6fc400ad9f43677bfae7e258e..9f6445c56369f00cd857890fe63b577b6db81350 100644 --- a/base/ca/src/com/netscape/ca/CertificateAuthority.java +++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java @@ -74,6 +74,7 @@ import org.mozilla.jss.pkix.primitive.Name; import com.netscape.certsrv.apps.CMS; import com.netscape.certsrv.authentication.IAuthToken; import com.netscape.certsrv.authority.ICertAuthority; +import com.netscape.certsrv.base.BadRequestDataException; import com.netscape.certsrv.base.EBaseException; import com.netscape.certsrv.base.EPropertyNotFound; import com.netscape.certsrv.base.IConfigStore; @@ -2680,8 +2681,16 @@ public class CertificateAuthority if (result != null && !result.equals(IRequest.RES_SUCCESS)) throw new EBaseException("createSubCA: certificate request submission resulted in error: " + result); RequestStatus requestStatus = request.getRequestStatus(); - if (requestStatus != RequestStatus.COMPLETE) - throw new EBaseException("createSubCA: certificate request did not complete; status: " + requestStatus); + if (requestStatus != RequestStatus.COMPLETE) { + // The request did not complete. Inference: something + // incorrect in the request (e.g. profile constraint + // violated). + String msg = "Failed to issue CA certificate. Final status: " + requestStatus + "."; + String errorMsg = request.getExtDataInString(IRequest.ERROR); + if (errorMsg != null) + msg += " Additional info: " + errorMsg; + throw new BadRequestDataException(msg); + } // Add certificate to nssdb cert = request.getExtDataInCert(IEnrollProfile.REQUEST_ISSUED_CERT); @@ -2697,7 +2706,10 @@ public class CertificateAuthority // log this error. CMS.debug("Error deleting new authority entry after failure during certificate generation: " + e2); } - throw new ECAException("Error creating lightweight CA certificate: " + e); + if (e instanceof BadRequestDataException) + throw (BadRequestDataException) e; // re-throw + else + throw new ECAException("Error creating lightweight CA certificate: " + e); } CertificateAuthority ca = new CertificateAuthority( diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java index 5ecabacd9a84a4d06e529ca0099f561155f7d791..7bca10fa1dfbfe7dbae5b5c0288c4c59c1075cf9 100644 --- a/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java +++ b/base/ca/src/org/dogtagpki/server/ca/rest/AuthorityService.java @@ -38,6 +38,7 @@ import javax.ws.rs.core.UriInfo; import com.netscape.certsrv.apps.CMS; import com.netscape.certsrv.authority.AuthorityData; import com.netscape.certsrv.authority.AuthorityResource; +import com.netscape.certsrv.base.BadRequestDataException; import com.netscape.certsrv.base.BadRequestException; import com.netscape.certsrv.base.ConflictingOperationException; import com.netscape.certsrv.base.EBaseException; @@ -207,7 +208,7 @@ public class AuthorityService extends PKIService implements AuthorityResource { audit(ILogger.SUCCESS, OpDef.OP_ADD, subCA.getAuthorityID().toString(), auditParams); return createOKResponse(readAuthorityData(subCA)); - } catch (IllegalArgumentException e) { + } catch (IllegalArgumentException | BadRequestDataException e) { throw new BadRequestException(e.toString()); } catch (CANotFoundException e) { throw new ResourceNotFoundException(e.toString()); -- 2.5.5 From ftweedal at redhat.com Tue Jun 28 06:29:50 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 28 Jun 2016 16:29:50 +1000 Subject: [Pki-devel] [PATCH] 0127 Fix build on Fedora 25 Message-ID: <20160628062950.GX4200@dhcp-40-8.bne.redhat.com> The attached patch fixes build on Fedora 25 (JAX-RS API JAR had moved). It also removes a bunch of redundant find_file directives. This can probably be done for many other JARs but I've kept it to just the one for now. No urgency to get this in. Cheers, Fraser -------------- next part -------------- From c818adaac1da2b43b42e199dc288d2c3b6a79bcc Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 28 Jun 2016 15:50:36 +1000 Subject: [PATCH] Fix build on Fedora 25 Look for the right JAX-RS API JAR (it has moved in Fedora 25). Also remove a lot of redundant 'find_file' operations for this JAR. --- base/CMakeLists.txt | 10 ++++++++++ base/ca/src/CMakeLists.txt | 7 ------- base/common/src/CMakeLists.txt | 7 ------- base/java-tools/src/CMakeLists.txt | 7 ------- base/kra/src/CMakeLists.txt | 7 ------- base/ocsp/src/CMakeLists.txt | 7 ------- base/server/cms/src/CMakeLists.txt | 7 ------- base/server/cmscore/src/CMakeLists.txt | 7 ------- base/server/tomcat/src/CMakeLists.txt | 7 ------- base/server/tomcat7/src/CMakeLists.txt | 7 ------- base/server/tomcat8/src/CMakeLists.txt | 7 ------- base/tks/src/CMakeLists.txt | 7 ------- base/tps/src/CMakeLists.txt | 14 -------------- 13 files changed, 10 insertions(+), 91 deletions(-) diff --git a/base/CMakeLists.txt b/base/CMakeLists.txt index b9d5c7bac81ef9dfde2b32fb2127a946bc38a94b..bb156ba48c008ec12fb52f4f35fbb853d9b0fff5 100644 --- a/base/CMakeLists.txt +++ b/base/CMakeLists.txt @@ -2,6 +2,16 @@ project(base) # The order is important! if (APPLICATION_FLAVOR_PKI_CORE) + + find_file(JAXRS_API_JAR + NAMES + jaxrs-api.jar + jboss-jaxrs-2.0-api.jar + PATHS + ${RESTEASY_LIB} + /usr/share/java + ) + add_subdirectory(test) add_subdirectory(symkey) add_subdirectory(util) diff --git a/base/ca/src/CMakeLists.txt b/base/ca/src/CMakeLists.txt index 2a43c8dbb4f88c22df244bb752ea963b2f0d646c..854ce28a25f729181a5009af13fde5bf0b4c013f 100644 --- a/base/ca/src/CMakeLists.txt +++ b/base/ca/src/CMakeLists.txt @@ -52,13 +52,6 @@ find_file(JACKSON_MAPPER_JAR /usr/share/java/jackson ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/common/src/CMakeLists.txt b/base/common/src/CMakeLists.txt index 072bd00307f6f299679c107836b2163ed0ff4b7c..ee41b2f47bdab9495c69167a6467cdc6471d86e3 100644 --- a/base/common/src/CMakeLists.txt +++ b/base/common/src/CMakeLists.txt @@ -83,13 +83,6 @@ find_file(XERCES_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/java-tools/src/CMakeLists.txt b/base/java-tools/src/CMakeLists.txt index 9a3c72fa2a7f1c631bc91f5af1e73536904a42b2..e7ca5db627cb3e398c4220029d2a78ade45c1d60 100644 --- a/base/java-tools/src/CMakeLists.txt +++ b/base/java-tools/src/CMakeLists.txt @@ -60,13 +60,6 @@ find_file(XERCES_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/kra/src/CMakeLists.txt b/base/kra/src/CMakeLists.txt index bfc8cdddaf150a4030e9c48ddebf8e8e828018a6..400ec016fe22ea156ea94bbe124ecd5eb8bc684c 100644 --- a/base/kra/src/CMakeLists.txt +++ b/base/kra/src/CMakeLists.txt @@ -61,13 +61,6 @@ find_file(COMMONS_CODEC_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/ocsp/src/CMakeLists.txt b/base/ocsp/src/CMakeLists.txt index d4a2009a9b390d5401a338c0b86559d0d3adac51..32fcc92dba9cf0f877af8970890df033de1d2375 100644 --- a/base/ocsp/src/CMakeLists.txt +++ b/base/ocsp/src/CMakeLists.txt @@ -46,13 +46,6 @@ find_file(LDAPJDK_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - # '${JAVA_LIB_INSTALL_DIR}' jars find_file(JSS_JAR NAMES diff --git a/base/server/cms/src/CMakeLists.txt b/base/server/cms/src/CMakeLists.txt index 33b1cd3baf8d321c7f1a2f50e5f3e8360c515695..93f4a8a4a275cc4997da1b9c031b830eee3190b3 100644 --- a/base/server/cms/src/CMakeLists.txt +++ b/base/server/cms/src/CMakeLists.txt @@ -90,13 +90,6 @@ find_file(XERCES_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/server/cmscore/src/CMakeLists.txt b/base/server/cmscore/src/CMakeLists.txt index ef12938652250b98187e1e8157d12df902179ade..32e4351ca947580ee75bd887bf78d1f1b5064181 100644 --- a/base/server/cmscore/src/CMakeLists.txt +++ b/base/server/cmscore/src/CMakeLists.txt @@ -83,13 +83,6 @@ find_file(XERCES_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/server/tomcat/src/CMakeLists.txt b/base/server/tomcat/src/CMakeLists.txt index 669cc8883043062119afdb5b55db28828d09e92f..4cb40ada4e83d4ec6ee9040e96f2c72aacec1ae3 100644 --- a/base/server/tomcat/src/CMakeLists.txt +++ b/base/server/tomcat/src/CMakeLists.txt @@ -83,13 +83,6 @@ find_file(XERCES_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/server/tomcat7/src/CMakeLists.txt b/base/server/tomcat7/src/CMakeLists.txt index f84369ccc33d47c11f32bc3e956431f501c121e4..18f0b91dccbb57d2f22a3396a7a92150dd910dda 100644 --- a/base/server/tomcat7/src/CMakeLists.txt +++ b/base/server/tomcat7/src/CMakeLists.txt @@ -83,13 +83,6 @@ find_file(XERCES_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/server/tomcat8/src/CMakeLists.txt b/base/server/tomcat8/src/CMakeLists.txt index 0f49ff9bc6366e65c289ab76e1ee32e6fac928fd..db1b9dc31c2291c98774066bdbb570f74efc3d7a 100644 --- a/base/server/tomcat8/src/CMakeLists.txt +++ b/base/server/tomcat8/src/CMakeLists.txt @@ -90,13 +90,6 @@ find_file(XERCES_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/tks/src/CMakeLists.txt b/base/tks/src/CMakeLists.txt index d1ebbb13d60a3205c3547ebf209c93a40f29612b..51f98c9b4ae4f9588e6d8d04295f20de90b75c5b 100644 --- a/base/tks/src/CMakeLists.txt +++ b/base/tks/src/CMakeLists.txt @@ -68,13 +68,6 @@ find_file(COMMONS_LANG_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar diff --git a/base/tps/src/CMakeLists.txt b/base/tps/src/CMakeLists.txt index b8b13a9934b376cf283b7c6d35c3c4548ce843eb..5e51f609c68f487fa9db1b0b4782a3627aab3cc6 100644 --- a/base/tps/src/CMakeLists.txt +++ b/base/tps/src/CMakeLists.txt @@ -28,13 +28,6 @@ find_file(COMMONS_LANG_JAR /usr/share/java ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(TOMCAT_CATALINA_JAR NAMES catalina.jar @@ -77,13 +70,6 @@ find_file(PKI_NSUTIL_JAR /usr/share/java/pki ) -find_file(JAXRS_API_JAR - NAMES - jaxrs-api.jar - PATHS - ${RESTEASY_LIB} -) - find_file(RESTEASY_JAXRS_JAR NAMES resteasy-jaxrs.jar -- 2.5.5 From edewata at redhat.com Tue Jun 28 17:37:28 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Jun 2016 12:37:28 -0500 Subject: [Pki-devel] Fixes pki-server subsystem --help options. In-Reply-To: <5768EB66.6020702@redhat.com> References: <5768EB66.6020702@redhat.com> Message-ID: On 6/21/2016 2:23 AM, Amol Kahat wrote: > Hi, > > Please review this patch. > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1340718 > > Thanks > Amol K. Thanks for the patch! Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Jun 28 17:45:53 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Jun 2016 12:45:53 -0500 Subject: [Pki-devel] Invalid instance exception fix. In-Reply-To: <5768F2E8.2050504@redhat.com> References: <5768F2E8.2050504@redhat.com> Message-ID: <312e89b1-544e-e137-ef08-17fdc8a2421a@redhat.com> On 6/21/2016 2:55 AM, Amol Kahat wrote: > Hi, > > Please review this patch. > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1348433 > > > Thanks > Amol K. Thanks! I pushed the patch with some changes for consistency. -- Endi S. Dewata From edewata at redhat.com Tue Jun 28 17:54:55 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Jun 2016 12:54:55 -0500 Subject: [Pki-devel] Fixes exception while invalid module. In-Reply-To: <5768F874.6020107@redhat.com> References: <5768F874.6020107@redhat.com> Message-ID: <6dde093d-d1cd-8697-3cb9-58606c73c990@redhat.com> On 6/21/2016 3:19 AM, Amol Kahat wrote: > Hi, > > Please review this patch. > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1348446 > > Thanks > Amol K I think to fix this problem properly the code should raise a CLIException (needs to be added) if it cannot find the module, then the main program should catch the exception and print the proper error message (and stack trace in verbose mode). See the code at the bottom of these files: * base/java-tools/bin/pki * base/server/sbin/pki-server I think those files should be changed into something like this: try: cli.execute(sys.argv) except subprocess.CalledProcessError as e: if cli.verbose: traceback.print_exc() print('ERROR: %s' % e) exit(e.returncode) except pki.cli.CLIException as e: if cli.verbose: traceback.print_exc() print('ERROR: %s' % e) exit(1) -- Endi S. Dewata From cfu at redhat.com Tue Jun 28 21:55:45 2016 From: cfu at redhat.com (Christina Fu) Date: Tue, 28 Jun 2016 14:55:45 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0142-Ticket-1308-RFE-Provide-ability-to-perform-off-card-.patch Message-ID: <5772F261.9050701@redhat.com> This is the patch to add missing serverKeygen params for non-encryption certs. By default it is disabled. thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0142-Ticket-1308-RFE-Provide-ability-to-perform-off-card-.patch Type: text/x-patch Size: 11149 bytes Desc: not available URL: From cfu at redhat.com Tue Jun 28 22:09:13 2016 From: cfu at redhat.com (Christina Fu) Date: Tue, 28 Jun 2016 15:09:13 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0142-Ticket-1308-RFE-Provide-ability-to-perform-off-card-.patch In-Reply-To: <5772F261.9050701@redhat.com> References: <5772F261.9050701@redhat.com> Message-ID: <5772F589.9020209@redhat.com> received verbal ack from Jack. Pushed to master: commit 98c12f05c38c9d21389f03a99f849151d9b68c84 thanks, Christina On 06/28/2016 02:55 PM, Christina Fu wrote: > This is the patch to add missing > serverKeygen params for non-encryption certs. By default it is disabled. > > thanks, > Christina > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Tue Jun 28 23:07:32 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 28 Jun 2016 17:07:32 -0600 Subject: [Pki-devel] [PATCH] 778 Fixed KRA cloning issue. In-Reply-To: <8fc52c84-c6dc-309c-6aac-cb3f8a6f3bd6@redhat.com> References: <8fc52c84-c6dc-309c-6aac-cb3f8a6f3bd6@redhat.com> Message-ID: <57730334.3000907@redhat.com> On 06/21/2016 01:03 PM, Endi Sukma Dewata wrote: > The pki pkcs12-import CLI has been modified not to import > certificates that already exist in the NSS database unless > specifically requested with the --overwrite parameter. This > will avoid changing the trust flags of the CA signing > certificate during KRA cloning. > > The some other classes have been modified to provide better > debugging information. > > https://fedorahosted.org/pki/ticket/2374 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Ran the following test: Steps to reproduce: 1. Install CA and KRA on master: $ ipa-server-install -U -r EXAMPLE.COM -p Secret123 -a Secret123 $ ipa-kra-install -p Secret123 2. Install CA and KRA on replica: $ ipa-client-install -U --server server.example.com --domain example.com \ --realm EXAMPLE.COM -p admin -w Secret123 $ echo Secret123 | kinit admin $ ipa-replica-install -U --setup-ca -p Secret123 -w Secret123 $ ipa-kra-install -p Secret123 Actual result: Success! The KRA installation on replica succeeded! ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Jun 28 23:19:34 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Jun 2016 18:19:34 -0500 Subject: [Pki-devel] [PATCH] 778 Fixed KRA cloning issue. In-Reply-To: <57730334.3000907@redhat.com> References: <8fc52c84-c6dc-309c-6aac-cb3f8a6f3bd6@redhat.com> <57730334.3000907@redhat.com> Message-ID: <8ee5820a-0eeb-cf0c-7f5f-7f4677a253bc@redhat.com> On 6/28/2016 6:07 PM, Matthew Harmsen wrote: > Ran the following test: > > Steps to reproduce: > > 1. Install CA and KRA on master: > > $ ipa-server-install -U -r EXAMPLE.COM -p Secret123 -a Secret123 > $ ipa-kra-install -p Secret123 > > 2. Install CA and KRA on replica: > > $ ipa-client-install -U --server server.example.com --domain example.com \ > --realm EXAMPLE.COM -p admin -w Secret123 > $ echo Secret123 | kinit admin > $ ipa-replica-install -U --setup-ca -p Secret123 -w Secret123 > $ ipa-kra-install -p Secret123 > > Actual result: Success! The KRA installation on replica succeeded! > > ACK Thanks! Pushed to master. -- Endi S. Dewata From cfu at redhat.com Wed Jun 29 01:03:35 2016 From: cfu at redhat.com (Christina Fu) Date: Tue, 28 Jun 2016 18:03:35 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0143-Ticket-2389-Installation-subsystem-certs-could-have-.patch Message-ID: <57731E67.8060704@redhat.com> This patch addresses https://fedorahosted.org/pki/ticket/2389 Installation: subsystem certs could have notAfter beyond CA signing cert in case of external or existing CA thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0143-Ticket-2389-Installation-subsystem-certs-could-have-.patch Type: text/x-patch Size: 3684 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 29 02:30:08 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Jun 2016 21:30:08 -0500 Subject: [Pki-devel] [PATCH] pki-cfu-0143-Ticket-2389-Installation-subsystem-certs-could-have-.patch In-Reply-To: <57731E67.8060704@redhat.com> References: <57731E67.8060704@redhat.com> Message-ID: <921c554a-fb76-29d2-481a-d57eee39d8c4@redhat.com> On 6/28/2016 8:03 PM, Christina Fu wrote: > This patch addresses https://fedorahosted.org/pki/ticket/2389 > Installation: subsystem certs could have notAfter beyond CA signing cert > in case of external or existing CA > > thanks, > Christina Just one thing, to help troubleshooting the exception should be chained and the original exception message should be appended, for example: } catch (Exception e) { throw new EProfileException( "Unable to get CA certificate: " + e.getMessage(), e); } The class/method name doesn't need to be included in the exception message since we can figure that out from the stack trace. ACK with the above change. -- Endi S. Dewata From akasurde at redhat.com Wed Jun 29 09:20:20 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 29 Jun 2016 14:50:20 +0530 Subject: [Pki-devel] [pki-devel][PATCH 0001] Added condition to verify instance id in db-schema-upgrade Message-ID: Hi All, Please review the patch. -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akasurde-0001-Added-condition-to-verify-instance-id-in-db-schema-u.patch Type: text/x-patch Size: 1144 bytes Desc: not available URL: From akasurde at redhat.com Wed Jun 29 12:43:59 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 29 Jun 2016 18:13:59 +0530 Subject: [Pki-devel] [pki-devel][PATCH 0002] Added fix for checking ldapmodify return code in db-schema-upgrade Message-ID: <9272490f-ea1d-fe6d-d72e-511903521bb3@redhat.com> Hi All, Please review the patch. -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akasurde-0002-Added-fix-for-checking-ldapmodify-return-code-in-db-.patch Type: text/x-patch Size: 1906 bytes Desc: not available URL: From cfu at redhat.com Wed Jun 29 16:15:22 2016 From: cfu at redhat.com (Christina Fu) Date: Wed, 29 Jun 2016 09:15:22 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0143-Ticket-2389-Installation-subsystem-certs-could-have-.patch In-Reply-To: <921c554a-fb76-29d2-481a-d57eee39d8c4@redhat.com> References: <57731E67.8060704@redhat.com> <921c554a-fb76-29d2-481a-d57eee39d8c4@redhat.com> Message-ID: <5773F41A.9060803@redhat.com> addressed comment. pushed to master: commit 659c90869a27871eda27fd730d00b0499873dae2 thanks! Christina On 06/28/2016 07:30 PM, Endi Sukma Dewata wrote: > On 6/28/2016 8:03 PM, Christina Fu wrote: >> This patch addresses https://fedorahosted.org/pki/ticket/2389 >> Installation: subsystem certs could have notAfter beyond CA signing cert >> in case of external or existing CA >> >> thanks, >> Christina > > Just one thing, to help troubleshooting the exception should be > chained and the original exception message should be appended, for > example: > > } catch (Exception e) { > throw new EProfileException( > "Unable to get CA certificate: " + e.getMessage(), e); > } > > The class/method name doesn't need to be included in the exception > message since we can figure that out from the stack trace. > > ACK with the above change. > From edewata at redhat.com Wed Jun 29 16:19:46 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 29 Jun 2016 11:19:46 -0500 Subject: [Pki-devel] [PATCH] 780 Fixed pki-server subsystem-cert-update. Message-ID: The pki-server subsystem-cert-update is supposed to restore the system certificate data and requests into CS.cfg. The command was broken since the CASubsystem class that contains the code to find the certificate requests from database was not loaded correctly. To fix the problem the CASubsystem class has been moved into the pki/server/__init__.py. All pki-server subsystem-* commands have been modified to check the validity of the instance. An option has been added to the pki-server subsystem-cert-show command to display the data and request of a particular system certificate. The redundant output of the pki-server subsystem-cert-update has been removed. The updated certificate data and request can be obtained using the pki-server subsystem-cert-show command. https://fedorahosted.org/pki/ticket/2385 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0780-Fixed-pki-server-subsystem-cert-update.patch Type: text/x-patch Size: 11943 bytes Desc: not available URL: From mharmsen at redhat.com Thu Jun 30 02:57:34 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 29 Jun 2016 20:57:34 -0600 Subject: [Pki-devel] [PATCH] Separate PKI Instances versus Shared PKI Instances Message-ID: <57748A9E.8050106@redhat.com> Please review the attached patch which addresses the following ticket: * PKI TRAC Ticket #1607 - [MAN] man pkispawn has inadequate description for shared vs non shared tomcat instance installation This ticket adds text to the pkispawn.8 man page to more adequately describe the differences between separated PKI instances and shared PKI instances including increasing the verbosity of the two examples related to these two deployment alternatives. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20160629-Separate-PKI-Instances-versus-Shared-PKI-Instances.patch Type: text/x-patch Size: 15267 bytes Desc: not available URL: From ftweedal at redhat.com Thu Jun 30 06:22:12 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 30 Jun 2016 16:22:12 +1000 Subject: [Pki-devel] cherry-pick 07b8413 to DOGTAG_10_2_BRANCH? Message-ID: <20160630062212.GN4200@dhcp-40-8.bne.redhat.com> Any objections to cherry-picking 07b8415312a7f37c566506ec516c4c74404402eb (fix for https://fedorahosted.org/pki/ticket/2221) to DOGTAG_10_2_BRANCH? Cheers, Fraser From akasurde at redhat.com Thu Jun 30 10:09:33 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 30 Jun 2016 15:39:33 +0530 Subject: [Pki-devel] [pki-devel][PATCH 0003] Added condition for checking instance id in kra commands Message-ID: Hi All, Please review this patch. Partially fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1351295 -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akasurde-0003-Added-condition-for-checking-instance-id-in-kra-comm.patch Type: text/x-patch Size: 6509 bytes Desc: not available URL: From akasurde at redhat.com Thu Jun 30 11:29:47 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 30 Jun 2016 16:59:47 +0530 Subject: [Pki-devel] [PATCH 0004] Updated notification message for kra-db-vlv-del command Message-ID: <9132056b-45e7-ed19-429d-bd6759cc1e04@redhat.com> Hi All, Please review this patch, Partially fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1351295 -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akasurde-0004-Updated-notification-message-for-kra-db-vlv-del-comm.patch Type: text/x-patch Size: 1408 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 30 15:10:32 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 30 Jun 2016 10:10:32 -0500 Subject: [Pki-devel] [PATCH] 0124 Add profiles container to LDAP if missing In-Reply-To: <20160622095315.GI4200@dhcp-40-8.bne.redhat.com> References: <20160622095315.GI4200@dhcp-40-8.bne.redhat.com> Message-ID: <4c87b044-bf00-8de0-ac99-27866b67eac5@redhat.com> On 6/22/2016 4:53 AM, Fraser Tweedale wrote: > The attached patch fixes https://fedorahosted.org/pki/ticket/2285. > See commit message and bz1323400[1] for full history and details. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1323400 > > The fix should be merged to master and DOGTAG_10_2_BRANCH, and a new > 10.2.x release cut for f23. > > I have an f23 COPR build containing the fix for anyone wishing to > test: > https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/packages/ > > Huge props to Adam Williamson for doing a lot of legwork in tracking > down the cause of this issue. > > Thanks, > Fraser ACK. When we have a proper database upgrade method we should consider converting this code into an upgrade script. -- Endi S. Dewata From edewata at redhat.com Thu Jun 30 15:30:53 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 30 Jun 2016 10:30:53 -0500 Subject: [Pki-devel] [PATCH] 0125 AuthInfoAccess: use default OCSP URI if configured In-Reply-To: <20160627063810.GT4200@dhcp-40-8.bne.redhat.com> References: <20160627063810.GT4200@dhcp-40-8.bne.redhat.com> Message-ID: <2f30c098-e820-3a54-4b1a-c5b662a7f5eb@redhat.com> On 6/27/2016 1:38 AM, Fraser Tweedale wrote: > Attached patch fixes https://fedorahosted.org/pki/ticket/2387 > (wanted for 10.3.4). > > Thanks, > Fraser Just one thing, maybe we should add a blank pki_default_ocsp_uri under the [CA] section in the default.cfg so people knows about this parameter? Regardless, it's ACKed. -- Endi S. Dewata From edewata at redhat.com Thu Jun 30 15:49:12 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 30 Jun 2016 10:49:12 -0500 Subject: [Pki-devel] [PATCH] 0126 Respond 400 if lightweight CA cert issuance fails In-Reply-To: <20160628025203.GW4200@dhcp-40-8.bne.redhat.com> References: <20160628025203.GW4200@dhcp-40-8.bne.redhat.com> Message-ID: <9cb95875-612d-7138-3f43-5b1e4ba8749b@redhat.com> On 6/27/2016 9:52 PM, Fraser Tweedale wrote: > The attached patch fixes https://fedorahosted.org/pki/ticket/2388. > Wanted for 10.3.4. > > Thanks, > Fraser Two things: 1. I don't think the patch author is correct :) 2. Existing issue, but while you're there could you chain the original exception to the ECAException? Assuming they're addressed, ACK. -- Endi S. Dewata From edewata at redhat.com Thu Jun 30 16:21:12 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 30 Jun 2016 11:21:12 -0500 Subject: [Pki-devel] [PATCH] 0127 Fix build on Fedora 25 In-Reply-To: <20160628062950.GX4200@dhcp-40-8.bne.redhat.com> References: <20160628062950.GX4200@dhcp-40-8.bne.redhat.com> Message-ID: <995469c7-944f-9fbd-dac1-ad07d146b942@redhat.com> On 6/28/2016 1:29 AM, Fraser Tweedale wrote: > The attached patch fixes build on Fedora 25 (JAX-RS API JAR had > moved). It also removes a bunch of redundant find_file directives. > This can probably be done for many other JARs but I've kept it to > just the one for now. > > No urgency to get this in. > > Cheers, > Fraser I suppose this is a fix for this ticket? https://fedorahosted.org/pki/ticket/2373 If so please assign the ticket to yourself and add a reference to this ticket in the patch description. The build still works on F23 & F24, so I think it's safe to push. ACK. -- Endi S. Dewata From cfu at redhat.com Thu Jun 30 21:11:16 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 30 Jun 2016 14:11:16 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0144-Ticket-1306-config-params-Add-granularity-to-token-t.patch Message-ID: <57758AF4.2040108@redhat.com> This patch is for https://fedorahosted.org/pki/ticket/1306 [RFE] Add granularity to token termination in TPS It 1. adds the missing parameters 2. adds a table for revocation code thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0144-Ticket-1306-config-params-Add-granularity-to-token-t.patch Type: text/x-patch Size: 20440 bytes Desc: not available URL: From jmagne at redhat.com Thu Jun 30 21:34:31 2016 From: jmagne at redhat.com (John Magne) Date: Thu, 30 Jun 2016 17:34:31 -0400 (EDT) Subject: [Pki-devel] [PATCH] Separate PKI Instances versus Shared PKI Instances In-Reply-To: <57748A9E.8050106@redhat.com> References: <57748A9E.8050106@redhat.com> Message-ID: <344787339.4035644.1467322471633.JavaMail.zimbra@redhat.com> ACK ----- Original Message ----- From: "Matthew Harmsen" To: "pki-devel" Sent: Wednesday, June 29, 2016 7:57:34 PM Subject: [Pki-devel] [PATCH] Separate PKI Instances versus Shared PKI Instances Please review the attached patch which addresses the following ticket: * PKI TRAC Ticket #1607 - [MAN] man pkispawn has inadequate description for shared vs non shared tomcat instance installation This ticket adds text to the pkispawn.8 man page to more adequately describe the differences between separated PKI instances and shared PKI instances including increasing the verbosity of the two examples related to these two deployment alternatives. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Thu Jun 30 21:50:16 2016 From: jmagne at redhat.com (John Magne) Date: Thu, 30 Jun 2016 17:50:16 -0400 (EDT) Subject: [Pki-devel] [pki-devel] [PATCH] 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch In-Reply-To: <577199CD.8040706@redhat.com> References: <1043889111.2156974.1466791695663.JavaMail.zimbra@redhat.com> <577199CD.8040706@redhat.com> Message-ID: <1644807974.4037304.1467323416743.JavaMail.zimbra@redhat.com> Addressed cfu's concerns and pushed to master for cond ACK. commit e326cd2f06bd651cdd87646eea94622e18cec28d Closing tiecket #1664 ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Monday, June 27, 2016 2:25:33 PM > Subject: Re: [Pki-devel] [pki-devel] [PATCH] 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch > > Just a few minor ones. > > * configuration parameters referencing token existence in tokendb should use > names begin with "tokendb". e.g. Done: Changed the names of the params as suggested. > tokendb.allowMultiActiveTokensPerUser.externalReg=false > tokendb.allowMultiActiveTokensPerUser.nonExternalReg=false > > * boolean allowMultiCerts -- I think the name is misleading. how about > alowMultiTokens > > * existing calls to tps.tdb.tdbHasActiveToken() need to be decided: > e.g. Both of these blocks of code I simply removed the action taken if the user has an active token, since they can no longer get there. The alternate case has been left untouched. The second occurrence is not likely to even happen since the transitions allowed will not usually allow to go from SUSPENDED to ACTIVE anyway. Case retained as a fallback. > 1. TPSEnrollProcessor.java search for tdbHasActiveToken (first occurrence) , > you will find that it is called with "TODO:" comment. I believe that whole > try/catch with the tps.tdb.tdbHasActiveToken(userid); call can be removed > since you already call that earlier in your patch > 2. TPSEnrollProcessor.java, the 2nd occurrence is when the enrolling token is > suspended. You need to look into what it is doing at the point and whether > that check can also be eliminated. > > thanks, > Christina > > On 06/24/2016 11:08 AM, John Magne wrote: > > > > Add ability to disallow TPS to enroll a single user on multiple tokens. > > This patch will install a check during the early portion of the > enrollment > process check a configurable policy whether or not a user should be > allowed > to have more that one active token. > > This check will take place only for brand new tokens not seen before. > The check will prevent the enrollment to proceed and will exit before the > system > has a chance to add this new token to the TPS tokendb. > > The behavior will be configurable for the the external reg and not > external reg scenarios > as follows: > > op.enroll.nonExternalReg.allowMultiActiveTokensUser=false > op.enroll.externalReg.allowMultiActiveTokensUser=false > > > _______________________________________________ > Pki-devel mailing list Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Thu Jun 30 21:54:29 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 30 Jun 2016 15:54:29 -0600 Subject: [Pki-devel] [pki-devel][PATCH] 0075-Generting-Symmetric-key-fails-with-key-generate-when.patch In-Reply-To: <926945076.2205852.1466814205230.JavaMail.zimbra@redhat.com> References: <926945076.2205852.1466814205230.JavaMail.zimbra@redhat.com> Message-ID: <57759515.30103@redhat.com> On 06/24/2016 06:23 PM, John Magne wrote: > Generting Symmetric key fails with key-generate when --usages verify is passed > > Ticket #1114 > > Minor adjustment to the man page for the key management commands to say > which usages are appropriate for sym keys and those appropriate for asym keys. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Thu Jun 30 21:56:46 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 30 Jun 2016 14:56:46 -0700 Subject: [Pki-devel] [PATCH] pki-cfu-0144-Ticket-1306-config-params-Add-granularity-to-token-t.patch In-Reply-To: <57758AF4.2040108@redhat.com> References: <57758AF4.2040108@redhat.com> Message-ID: <5775959E.7030001@redhat.com> got verbal ack from Jack. Pushed to master: commit 63a58cf51ef2982e8a35eff1f98dd42453e5681e thanks, Christina On 06/30/2016 02:11 PM, Christina Fu wrote: > This patch is for https://fedorahosted.org/pki/ticket/1306 [RFE] Add > granularity to token termination in TPS > It > 1. adds the missing parameters > 2. adds a table for revocation code > > thanks, > Christina > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Thu Jun 30 22:04:47 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 30 Jun 2016 15:04:47 -0700 Subject: [Pki-devel] [PATCH] Bug 1203407 - tomcatjss: missing ciphers Message-ID: <5775977F.3000108@redhat.com> The tomcatjss patch address: *Bug 1203407* -tomcatjss: missing ciphers 2nd patch is the accompanying dogtag change to remove references to the unsupported ciphers. There is no critical dependency of the new tomcatjss. thanks, Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tomcatjss-missing-ciphers.patch Type: text/x-patch Size: 4526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-cfu-0145-Bugzilla-1203407-tomcatjss-missing-ciphers.patch Type: text/x-patch Size: 8192 bytes Desc: not available URL: From cfu at redhat.com Thu Jun 30 23:43:19 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 30 Jun 2016 16:43:19 -0700 Subject: [Pki-devel] [PATCH] Bug 1203407 - tomcatjss: missing ciphers In-Reply-To: <5775977F.3000108@redhat.com> References: <5775977F.3000108@redhat.com> Message-ID: <5775AE97.7070102@redhat.com> got verbal ack from Jack. Pushed to master (the dogtag patch): commit f0ad71e8a4fbae665a6b4875cce5b82895ad74f0 tomcatjss will be built in the next few days. Christina On 06/30/2016 03:04 PM, Christina Fu wrote: > The tomcatjss patch address: > *Bug 1203407* > -tomcatjss: missing ciphers > > 2nd patch is the accompanying dogtag change to remove references to > the unsupported ciphers. There is no critical dependency of the new > tomcatjss. > > thanks, > Christina > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Thu Jun 30 23:44:58 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 30 Jun 2016 18:44:58 -0500 Subject: [Pki-devel] [pki-devel][PATCH 0001] Added condition to verify instance id in db-schema-upgrade In-Reply-To: References: Message-ID: <0582557c-582b-b133-77e7-ae0a467de32b@redhat.com> On 6/29/2016 4:20 AM, Abhijeet Kasurde wrote: > Hi All, > > Please review the patch. > > -- > Thanks, > Abhijeet Kasurde Thanks! Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Jun 30 23:47:03 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 30 Jun 2016 18:47:03 -0500 Subject: [Pki-devel] [pki-devel][PATCH 0002] Added fix for checking ldapmodify return code in db-schema-upgrade In-Reply-To: <9272490f-ea1d-fe6d-d72e-511903521bb3@redhat.com> References: <9272490f-ea1d-fe6d-d72e-511903521bb3@redhat.com> Message-ID: <80d4c4ac-5dc6-5c05-b73e-47e2b8717a45@redhat.com> On 6/29/2016 7:43 AM, Abhijeet Kasurde wrote: > Hi All, > > Please review the patch. > > -- > Thanks, > Abhijeet Kasurde Thanks! Pushed to master with some changes to handle all LDAP errors instead of some specific ones. -- Endi S. Dewata