Re: [Pki-devel] Gerrit submit type
After discussion in CS meeting: Policy now set to "rebase if necessary". Ade On Mon, 2017-10-09 at 12:38 -0400, Ade Lee wrote: > Can you describe a bit the ramifications of this change and why it is > needed? > > I notice that most of the Openstack projects use the default "Merge > If > Necessary", and want to understand (or at least document) why we want > to do things differently. > > Ade > > On Sat, 2017-10-07 at 13:26 +1000, Fraser Tweedale wrote: > > To whoever has management permission on gerrithub, > > > > Could you please change the `Submit Type' config to `Rebase if > > Necessary'? This will avoid explicit merge commits without the > > developer having to explicitly rebase the change before submitting. > > > > https://gerrit-review.googlesource.com/Documentation/project-config > > ur > > ation.html#submit_type > > > > Thanks, > > Fraser ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0163..0165 Include revocation reason in REST cert data
ACK
On Wed, 2017-02-22 at 12:12 +1000, Fraser Tweedale wrote:
> The following patches add the revocation reason to the REST cert
> data (i.e. GET /ca/rest/certs/{id}).
>
> Patches 0163 and 0164 were pushed under trivial rule.
>
> Please review 0165.
>
> Thanks,
> Fraser
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 342 Add option to remove signing cert record (for migration)
Add option to remove signing cert entry
In the migration case, it is useful to delete the initially
created signing certificate database record and have that be
imported through the ldif data import instead.
Therefore, we add an option to remove this entry. The user
also needs to provide the serial number for the entry.
This resolves the following tickets/BZs:
BZ# 1409949/Trac 2573 - CA Certificate Issuance Date displayed
on CA website incorrect
BZ# 1409946/Trac 2571 - Request ID undefined for CA signing
certificate
Please review,
AdeFrom 56dd82d41c4d8dbf8678cbc6dfc7c1c05978f874 Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Fri, 20 Jan 2017 11:01:41 -0500
Subject: [PATCH] Add option to remove signing cert entry
In the migration case, it is useful to delete the initially
created signing certificate database record and have that be
imported through the ldif data import instead.
Therefore, we add an option to remove this entry. The user
also needs to provide the serial number for the entry.
This resolves the following tickets/BZs:
BZ# 1409949/Trac 2573 - CA Certificate Issuance Date displayed
on CA website incorrect
BZ# 1409946/Trac 2571 - Request ID undefined for CA signing
certificate
---
.../server/ca/rest/CAInstallerService.java | 47 --
.../certsrv/system/ConfigurationRequest.java | 32 +++
base/server/etc/default.cfg| 2 +
.../python/pki/server/deployment/pkihelper.py | 5 +++
4 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/CAInstallerService.java b/base/ca/src/org/dogtagpki/server/ca/rest/CAInstallerService.java
index 3c7e4831968156cabea48437ab8ae88bf9464fda..b7a41e73eafa2c5390605017f21703968c32d7f9 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/CAInstallerService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/CAInstallerService.java
@@ -24,8 +24,7 @@ import java.net.MalformedURLException;
import java.net.URL;
import java.util.StringTokenizer;
-import netscape.ldap.LDAPAttribute;
-
+import org.apache.commons.lang.StringUtils;
import org.dogtagpki.server.rest.SystemConfigService;
import com.netscape.certsrv.apps.CMS;
@@ -41,6 +40,10 @@ import com.netscape.cms.servlet.csadmin.ConfigurationUtils;
import com.netscape.cmscore.base.LDAPConfigStore;
import com.netscape.cmscore.profile.LDAPProfileSubsystem;
+import netscape.ldap.LDAPAttribute;
+import netscape.ldap.LDAPConnection;
+import netscape.ldap.LDAPException;
+
/**
* @author alee
*
@@ -93,6 +96,16 @@ public class CAInstallerService extends SystemConfigService {
CMS.debug(e);
throw new PKIException("Error enabling profile subsystem");
}
+
+if (request.deleteSigningCertRecord()) {
+try {
+String serialNumber = request.getSigningCertSerialNumber();
+deleteSigningRecord(serialNumber);
+} catch (Exception e) {
+CMS.debug(e);
+throw new PKIException("Error deleting signing cert record:" + e, e);
+}
+}
}
@Override
@@ -189,9 +202,37 @@ public class CAInstallerService extends SystemConfigService {
configStore.commit(false /* no backup */);
}
+private void deleteSigningRecord(String serialNumber) throws EBaseException, LDAPException {
+
+if (StringUtils.isEmpty(serialNumber)) {
+throw new PKIException("signing certificate serial number not specified in configuration request");
+}
+
+LDAPConnection conn = null;
+try {
+IConfigStore dbCfg = cs.getSubStore("internaldb");
+ILdapConnFactory dbFactory = CMS.getLdapBoundConnFactory("CAInstallerService");
+dbFactory.init(dbCfg);
+conn = dbFactory.getConn();
+
+String basedn = dbCfg.getString("basedn", "");
+String dn = "cn=" + serialNumber + ",ou=certificateRepository,ou=ca," + basedn;
+
+conn.delete(dn);
+} finally {
+try {
+if (conn != null)
+conn.disconnect();
+} catch (LDAPException e) {
+CMS.debug(e);
+CMS.debug("releaseConnection: " + e);
+}
+}
+}
+
private void configureStartingCRLNumber(ConfigurationRequest data) {
CMS.debug("CAInstallerService:configureStartingCRLNumber entering.");
-cs.putString("ca.crl.MasterCRL.startingCrlNumber",data.getStartingCRLNumber() );
+cs.putString("ca.crl.MasterCRL.startingCrlNumber",data.getStartingCRLNumber());
}
private void disableCRLCachingAndGenerationForClone(ConfigurationRequest data) throws MalformedURLExce
Re: [Pki-devel] [PATCH] 339-340 fixes for new Key REST logic
Acked by Endi. Pushed to Master. On Mon, 2016-11-21 at 18:33 -0500, Ade Lee wrote: > Patch 340: > commit 0e1c6e0634f5d3b3d4b8a3d7293b23f1953cf542 > Author: Ade Lee <a...@redhat.com> > Date: Mon Nov 21 17:42:11 2016 -0500 > > Fix bug in getting secrets from approved request > > When request was approved and retrieved through the rest > interface, the corresponding volatile requests object was not > created due to the new flow. This makes sure the volatile > request > is created. > > Patch 339: > commit 2e37a2fe6173a9968fd76fb7ff93e7cc188aa700 > Author: Ade Lee <a...@redhat.com> > Date: Mon Nov 21 12:01:09 2016 -0500 > > Add python-client code for key resource changes > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 339-340 fixes for new Key REST logic
Patch 340:
commit 0e1c6e0634f5d3b3d4b8a3d7293b23f1953cf542
Author: Ade Lee <a...@redhat.com>
Date: Mon Nov 21 17:42:11 2016 -0500
Fix bug in getting secrets from approved request
When request was approved and retrieved through the rest
interface, the corresponding volatile requests object was not
created due to the new flow. This makes sure the volatile request
is created.
Patch 339:
commit 2e37a2fe6173a9968fd76fb7ff93e7cc188aa700
Author: Ade Lee <a...@redhat.com>
Date: Mon Nov 21 12:01:09 2016 -0500
Add python-client code for key resource changesFrom 0e1c6e0634f5d3b3d4b8a3d7293b23f1953cf542 Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Mon, 21 Nov 2016 17:42:11 -0500
Subject: [PATCH 340/340] Fix bug in getting secrets from approved request
When request was approved and retrieved through the rest
interface, the corresponding volatile requests object was not
created due to the new flow. This makes sure the volatile request
is created.
---
.../org/dogtagpki/server/kra/rest/KeyService.java | 35 +++---
.../netscape/cms/servlet/key/KeyRequestDAO.java| 43 --
2 files changed, 37 insertions(+), 41 deletions(-)
diff --git a/base/kra/src/org/dogtagpki/server/kra/rest/KeyService.java b/base/kra/src/org/dogtagpki/server/kra/rest/KeyService.java
index 1d67cbc7b18b83ba3b21c675d231c365d69ccdcc..d2c24c888c3a8835fe69cb087c6986887bf1ef41 100644
--- a/base/kra/src/org/dogtagpki/server/kra/rest/KeyService.java
+++ b/base/kra/src/org/dogtagpki/server/kra/rest/KeyService.java
@@ -197,7 +197,8 @@ public class KeyService extends PKIService implements KeyResource {
KeyRequestDAO reqDAO = new KeyRequestDAO();
try {
-request = reqDAO.createRecoveryRequest(data, uriInfo, getRequestor(), getAuthToken(), ephemeral);
+request = reqDAO.createRecoveryRequest(data, uriInfo, getRequestor(),
+getAuthToken(), ephemeral);
} catch (EBaseException e) {
throw new PKIException(e.getMessage(), e);
}
@@ -270,6 +271,7 @@ public class KeyService extends PKIService implements KeyResource {
String method = "KeyService.getKey:";
auditInfo = method;
KeyData keyData;
+KeyRequestDAO dao = new KeyRequestDAO();
CMS.debug(method + "begins.");
if (data == null) {
@@ -294,16 +296,9 @@ public class KeyService extends PKIService implements KeyResource {
auditInfo += ";synchronous=" + Boolean.toString(synchronous);
auditInfo += ";ephemeral=" + Boolean.toString(ephemeral);
-
-// get data from the KeyRecoveryRequest
-String transWrappedSessionKey = data.getTransWrappedSessionKey();
-String sessionWrappedPassphrase = data.getSessionWrappedPassphrase();
-
// get data from IRequest
-Hashtable<String, Object> requestParams = kra.getVolatileRequest(request.getRequestId());
-if(requestParams == null) {
-throw new PKIException("Can't obtain Volatile requestParams in getKey!");
-}
+Hashtable<String, Object> requestParams = dao.getTransientData(request);
+
String sessWrappedKeyData = (String) requestParams.get(IRequest.SECURITY_DATA_SESS_WRAPPED_DATA);
String passWrappedKeyData = (String) requestParams.get(IRequest.SECURITY_DATA_PASS_WRAPPED_DATA);
String nonceData = (String) requestParams.get(IRequest.SECURITY_DATA_IV_STRING_OUT);
@@ -318,18 +313,7 @@ public class KeyService extends PKIService implements KeyResource {
// the info now needed to process the recovery request.
nonceData = data.getNonceData();
-
-if (sessionWrappedPassphrase != null) {
-requestParams.put(IRequest.SECURITY_DATA_SESS_PASS_PHRASE, sessionWrappedPassphrase);
-}
-
-if (transWrappedSessionKey != null) {
-requestParams.put(IRequest.SECURITY_DATA_TRANS_SESS_KEY, transWrappedSessionKey);
-}
-
-if (nonceData != null) {
-requestParams.put(IRequest.SECURITY_DATA_IV_STRING_IN, nonceData);
-}
+dao.setTransientData(data, request);
try {
if (!synchronous) {
@@ -682,6 +666,13 @@ public class KeyService extends PKIService implements KeyResource {
throw new UnauthorizedException("Request not approved");
}
+KeyRequestDAO dao = new KeyRequestDAO();
+try {
+dao.setTransientData(data, request);
+} catch(EBaseException e) {
+throw new PKIException("Cannot set transient data", e);
+}
+
String passphrase = data.getPassphrase();
byte pkcs12[] = null;
try {
diff --git a/base/server/cms/src/com/netscape/cms/servle
Re: [Pki-devel] [PATCH] 331-333 add support for synchronous key archival and recovery requests.
Thanks for reviews (Endi and Jack). Pushed to master with a few minor changes to auditing. Ade On Wed, 2016-11-09 at 10:59 -0500, Ade Lee wrote: > Based on feedback by Endi, I have reworked the patches. > As Endi pointed out, it makes little sense for the client to > determine > whether or not a request is stored to ldap or not. This should be a > server side decision. > > Accordingly, I have modified retrieveKey() as follows: > > When clients call retrieveKey(), three possible alternatives now > obtain: > > 1. client passes in an approved request. Request is processed > and the secret is retrieved. > 2. client passes in key_id and wrapping parameters and either: > a) request can be processed immediately and synchronously > and request is created, and secret is returned. > b) request cannot be processed immediately. Recovery request > is created and request_id returned to the client > > Depending on server configuration, the requests in case (2a) will be > stored in ldap or will be ephemeral (in memory only). > > More complicated realm based logic to determine if requests > can be processed synchronously (and possibly ephemerally) will be > added > in a later patch. > > Python client patches coming soon as well. > > * > ** > You can test the patches as follows: > > (archive and retrieve a passphrase) > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > `hostname` -p 8443 key-archive --passphrase "foobar" --clientKeyID > "test_1" > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > `hostname` -p 8443 key-retrieve --keyID 0xc > > (retrieve the passphrase using an approved recovery request) > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > `hostname` -p 8443 key-retrieve --keyID 0xc > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > `hostname` -p 8443 key-request-review --action approve 0x36 > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > `hostname` -p 8443 key-retrieve --requestID 0x36 > > The above should create requests (archival and recovery) in LDAP. > Add the following to CS.cfg (and restart the KRA): > > kra.ephemeral=true > > Redo the above tests, and no requests should be written to LDAP. > > Finally, test a case where more than one approval is needed. > Add the following to CS.cfg and restart the KRA. > > kra.noOfRequiredSecurityDataRecoveryAgents=2 > > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > `hostname` -p 8443 key-retrieve --keyID 0xc > > This should return a recovery request ID (which will be written to > LDAP). > You will need another agent to approve this request before it can be > used to retrieve the key. > > Ade > > On Fri, 2016-11-04 at 16:11 -0400, Ade Lee wrote: > > > > Hi all, > > > > This is in support of Ticket https://fedorahosted.org/pki/ticket/25 > > 32 > > > > This is preliminary set of patches - just so you can see what I'm > > doing > > in case I need to change anything. > > > > Note: With the changes, you can archive a secret like this: > > > > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > > `hostname` -p 8443 key-archive --passphrase "ooga booga" -- > > clientKeyID > > "test_1" > > > > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > > `hostname` -p 8443 key-archive --passphrase "ooga booga" -- > > clientKeyID > > "test_2" --express > > > > The first invocation will archive a secret and create an archival > > request in LDAP. The second will create one only in memory - and > > will > > not store it in LDAP. > > > > You can of course, see the requests created using - > > > > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > > `hostname` -p 8443 key-request-find > > > > For retrieving the secret, you can do either: > > > > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > > aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 > > > > pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h > > aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 --express > > > > The first will retrieve the secret while creating a retrieval > > request. > > The second will create a retrieval request only in memory, and will > > not > > write it to LDAP. > > > > In both cases, there should be audit logs both for retrieval and > > archival. > > > > Thanks, > > Ade > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 865 Moved policy framework classes to org.dogtagpki.legacy.
ACK On Fri, 2016-11-04 at 17:54 -0500, Endi Sukma Dewata wrote: > To discourage the use of policy framework, the framework classes > have been moved into org.dogtagpki.legacy. > > https://fedorahosted.org/pki/ticket/6 > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 864 Generalized list of files in CMakeLists.txt.
ACK On Fri, 2016-11-04 at 17:43 -0500, Endi Sukma Dewata wrote: > The list of source and class files in some CMake files have been > generalized to allow renaming Java packages without changing the > CMake files again. > > https://fedorahosted.org/pki/ticket/6 > > I've verified that the new CMake files do not change the content of > the > JAR files. > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 863 Reverted policy framework deprecation.
ACK On Thu, 2016-11-03 at 23:14 -0500, Endi Sukma Dewata wrote: > To reduce Eclipse warnings, classes and methods related to policy > framework have been undeprecated. In the future the policy > framework may be removed since it has already been replaced with > the profile framework. > > https://fedorahosted.org/pki/ticket/6 > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 861 Replaced deprecated DefaultHttpClient.
ACK On Thu, 2016-11-03 at 18:25 -0500, Endi Sukma Dewata wrote: > The deprecated DefaultHttpClient in SubsystemClient, CRMFPopClient, > and OCSPProcessor has been replaced with HttpClientBuilder. > > https://fedorahosted.org/pki/ticket/2531 > > Pushed to master under trivial/one-liner rule. > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0135 Do not attempt LWCA key retrieval for host authority
ACK On Thu, 2016-09-22 at 12:13 +1000, Fraser Tweedale wrote: > Hi team, > > Please review the attached patch which fixes a regression in > two-step externally-signed CA installation. It is destined for 10.3 > branch as well as master. > > https://fedorahosted.org/pki/ticket/2466 > > Cheers, > Fraser > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0131..0132 Fix LWCA entryUSN handling
pushed to master On Tue, 2016-09-06 at 17:17 -0400, Ade Lee wrote: > We still dont know how this state happened, but .. ack. > > Ade > On Wed, 2016-08-24 at 15:36 +1000, Fraser Tweedale wrote: > > The attached patches address a couple of issues related to handling > > entryUSN attribute when reading lightweight CA entries. > > > > https://fedorahosted.org/pki/ticket/2444 > > > > Thanks, > > Fraser > > ___ > > Pki-devel mailing list > > Pki-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0130 Prevent deletion of host CA cert and key from NSSDB
ack On Wed, 2016-08-24 at 15:34 +1000, Fraser Tweedale wrote: > Hi, > > Attached patch fixes https://fedorahosted.org/pki/ticket/2443. > > Thanks, > Fraser > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0131..0132 Fix LWCA entryUSN handling
We still dont know how this state happened, but .. ack. Ade On Wed, 2016-08-24 at 15:36 +1000, Fraser Tweedale wrote: > The attached patches address a couple of issues related to handling > entryUSN attribute when reading lightweight CA entries. > > https://fedorahosted.org/pki/ticket/2444 > > Thanks, > Fraser > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 233 - fix incrorrect URLs in CertRequestInfos
Pushed to master on basis of trivial rule. Ade On Fri, 2016-09-02 at 16:14 -0400, Ade Lee wrote: >Fix CertRequestInfo URLs > > The URLs were generated by a UriBuilder that referred to the > resource's > annotated path. This top-level path changed though, even if the > underlying > paths did not. Replace this with a reference to the getX methods > instead. > > Also fixed a few eclipse flagged warnings (unused imports etc). > > Ticket 2447 > > Please review .. > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0128 Fix CA OCSP responder when LWCA's are not in use
ACK On Wed, 2016-07-27 at 11:32 +1000, Fraser Tweedale wrote: > Hi team, > > The attached patch fixes https://fedorahosted.org/pki/ticket/2420. > > Thanks, > Fraser > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 329 - add pkispawn option to disable Master CRL
Add pkispawn option to disable Master CRL. This is useful in the migration case. Please review, Ade From fe1e82ff8f0e89c0c359064cfb749ae475125c2a Mon Sep 17 00:00:00 2001 From: Ade Lee <a...@redhat.com> Date: Wed, 3 Aug 2016 23:55:53 -0400 Subject: [PATCH] Add pkispawn option to disable Master CRL --- base/ca/shared/conf/CS.cfg| 2 +- base/server/config/pkislots.cfg | 1 + base/server/etc/default.cfg | 1 + base/server/python/pki/server/deployment/pkiparser.py | 4 4 files changed, 7 insertions(+), 1 deletion(-) diff --git a/base/ca/shared/conf/CS.cfg b/base/ca/shared/conf/CS.cfg index 68e79a48f650c6d39d0324c071c2f3b7e9d74515..3beb45c5392427dec411fda0bb12769b9d279f43 100644 --- a/base/ca/shared/conf/CS.cfg +++ b/base/ca/shared/conf/CS.cfg @@ -578,7 +578,7 @@ ca.crl.MasterCRL.unexpectedExceptionLoopMax=10 ca.crl.MasterCRL.class=com.netscape.ca.CRLIssuingPoint ca.crl.MasterCRL.dailyUpdates=1:00 ca.crl.MasterCRL.description=CA's complete Certificate Revocation List -ca.crl.MasterCRL.enable=true +ca.crl.MasterCRL.enable=[MASTER_CRL_ENABLE] ca.crl.MasterCRL.enableCRLCache=true ca.crl.MasterCRL.enableCRLUpdates=true ca.crl.MasterCRL.enableCacheTesting=false diff --git a/base/server/config/pkislots.cfg b/base/server/config/pkislots.cfg index 3873b83652e9fd0c9849dafcb1c50dcf5613e5c5..d806c1fbfd6fe430b4ca9adf4a88a666aae2acea 100644 --- a/base/server/config/pkislots.cfg +++ b/base/server/config/pkislots.cfg @@ -1,6 +1,7 @@ [Tomcat] application_version=[APPLICATION_VERSION] INSTALL_TIME_SLOT=[INSTALL_TIME] +MASTER_CRL_ENABLE_SLOT=[MASTER_CRL_ENABLE] NUXWDOG_JNI_PATH_SLOT=[NUXWDOG_JNI_PATH] PKI_ADMIN_SECURE_PORT_SLOT=[PKI_ADMIN_SECURE_PORT] PKI_ADMIN_SECURE_PORT_CONNECTOR_NAME_SLOT=[PKI_ADMIN_SECURE_PORT_CONNECTOR_NAME] diff --git a/base/server/etc/default.cfg b/base/server/etc/default.cfg index 24e4a43ff9007dd77c8794c7198c7eb96059ead9..cfbd289cc880db3bf4ed836f7dabc5168365bfd0 100644 --- a/base/server/etc/default.cfg +++ b/base/server/etc/default.cfg @@ -335,6 +335,7 @@ pki_ds_database=%(pki_instance_name)s-CA pki_ds_hostname=%(pki_hostname)s pki_subsystem_name=CA %(pki_hostname)s %(pki_https_port)s pki_share_db=False +pki_master_crl_enable=True # Default OCSP URI added by AuthInfoAccessExtDefault if the profile # config is blank. If both are blank, the value is constructed diff --git a/base/server/python/pki/server/deployment/pkiparser.py b/base/server/python/pki/server/deployment/pkiparser.py index 3e5d35575abf7b65e881211cba4b4db880bf35d8..115f3ca4506fec310ae1e5e88ccb0ecb0c4c609b 100644 --- a/base/server/python/pki/server/deployment/pkiparser.py +++ b/base/server/python/pki/server/deployment/pkiparser.py @@ -946,6 +946,10 @@ class PKIConfigParser: self.mdict['SERVER_KEYGEN_SLOT'] = \ self.mdict['pki_enable_server_side_keygen'] +if self.mdict['pki_subsystem'] == "CA": +self.mdict['MASTER_CRL_ENABLE_SLOT'] = \ +self.mdict['pki_master_crl_enable'] + self.mdict['TOMCAT_CFG_SLOT'] = \ self.mdict['pki_target_tomcat_conf'] self.mdict['TOMCAT_INSTANCE_COMMON_LIB_SLOT'] = \ -- 2.4.3 ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 328 - fix trust settingd for pki client-cert-import
Fix client-cert-import to set provided trust bits
Ticket 2412
From 0fd441eee679001a0c137193e32759a1068e839e Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Fri, 29 Jul 2016 14:42:35 +0100
Subject: [PATCH] Fix client-cert-import to set provided trust bits
Ticket 2412
---
.../netscape/cmstools/client/ClientCertImportCLI.java| 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/base/java-tools/src/com/netscape/cmstools/client/ClientCertImportCLI.java b/base/java-tools/src/com/netscape/cmstools/client/ClientCertImportCLI.java
index 9625440c01f85935b3a1d3fde8ccd82aad146452..a920079c456ab14d1c5d47b5432ee725859b4357 100644
--- a/base/java-tools/src/com/netscape/cmstools/client/ClientCertImportCLI.java
+++ b/base/java-tools/src/com/netscape/cmstools/client/ClientCertImportCLI.java
@@ -83,7 +83,7 @@ public class ClientCertImportCLI extends CLI {
option.setArgName("serial number");
options.addOption(option);
-option = new Option(null, "trust", true, "Trust attributes. Default: u,u,u.");
+option = new Option(null, "trust", true, "Trust attributes.");
option.setArgName("trust attributes");
options.addOption(option);
}
@@ -140,13 +140,16 @@ public class ClientCertImportCLI extends CLI {
String pkcs12PasswordPath = cmd.getOptionValue("pkcs12-password-file");
boolean importFromCAServer = cmd.hasOption("ca-server");
String serialNumber = cmd.getOptionValue("serial");
-String trustAttributes = cmd.getOptionValue("trust", "u,u,u");
+String trustAttributes = cmd.getOptionValue("trust");
// load the certificate
if (certPath != null) {
if (verbose) System.out.println("Importing certificate from " + certPath + ".");
+if (trustAttributes == null)
+trustAttributes = "u,u,u";
+
importCert(
mainCLI.certDatabase.getAbsolutePath(),
certPath,
@@ -157,7 +160,8 @@ public class ClientCertImportCLI extends CLI {
if (verbose) System.out.println("Importing CA certificate from " + caCertPath + ".");
-trustAttributes = "CT,c,";
+if (trustAttributes == null)
+trustAttributes = "CT,c,";
importCert(
mainCLI.certDatabase.getAbsolutePath(),
@@ -218,7 +222,8 @@ public class ClientCertImportCLI extends CLI {
out.write(bytes);
}
-trustAttributes = "CT,c,";
+if (trustAttributes == null)
+trustAttributes = "CT,c,";
importCert(
mainCLI.certDatabase.getAbsolutePath(),
@@ -250,6 +255,9 @@ public class ClientCertImportCLI extends CLI {
out.write(encoded);
}
+if (trustAttributes == null)
+trustAttributes = "u,u,u";
+
importCert(
mainCLI.certDatabase.getAbsolutePath(),
certFile.getAbsolutePath(),
--
2.4.3
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 326 - re-license the python client code
Small mod on wording (from legal) to allow v3+, and modify spec file to include the new license file. Ade On Thu, 2016-07-28 at 19:18 +0100, Ade Lee wrote: > In order to keep the Dogtag plugin in the Openstack Barbican source > tree, it is necessarily to re-license the Python client code to be > LGPLv3 as opposed to GPLv2, to comply with Openstack rules for > licensing of dependencies. > > http://governance.openstack.org/reference/licensing.html > > This patch makes the relevant changes. Please review. > Thanks, > > Ade > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-develFrom e3199497206533ed3bad04fb36706efd094cf36c Mon Sep 17 00:00:00 2001 From: Ade Lee <a...@redhat.com> Date: Thu, 28 Jul 2016 10:36:50 +0100 Subject: [PATCH] Re-license the python client files to LGPLv3 --- base/common/LICENSE.LESSER | 170 + base/common/python/pki/__init__.py | 13 +-- base/common/python/pki/account.py | 13 +-- base/common/python/pki/authority.py| 13 +-- base/common/python/pki/cert.py | 13 +-- base/common/python/pki/cli/__init__.py | 13 +-- base/common/python/pki/cli/pkcs12.py | 13 +-- base/common/python/pki/client.py | 13 +-- base/common/python/pki/crypto.py | 13 +-- base/common/python/pki/encoder.py | 17 base/common/python/pki/feature.py | 13 +-- base/common/python/pki/key.py | 13 +-- base/common/python/pki/kra.py | 13 +-- base/common/python/pki/nssdb.py| 13 +-- base/common/python/pki/profile.py | 13 +-- base/common/python/pki/system.py | 13 +-- base/common/python/pki/systemcert.py | 13 +-- base/common/python/pki/upgrade.py | 13 +-- base/common/python/pki/util.py | 13 +-- base/common/python/setup.py| 16 ++-- specs/pki-core.spec| 2 + 21 files changed, 316 insertions(+), 110 deletions(-) create mode 100644 base/common/LICENSE.LESSER diff --git a/base/common/LICENSE.LESSER b/base/common/LICENSE.LESSER new file mode 100644 index ..ca70b83cce4cdb9a5677aa43b5ff93d1865a --- /dev/null +++ b/base/common/LICENSE.LESSER @@ -0,0 +1,170 @@ +The Python client code is released under LGPLv3+. +This license is provided below: +** + + GNU LESSER GENERAL PUBLIC LICENSE + Version 3, 29 June 2007 + + Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + This version of the GNU Lesser General Public License incorporates +the terms and conditions of version 3 of the GNU General Public +License, supplemented by the additional permissions listed below. + + 0. Additional Definitions. + + As used herein, "this License" refers to version 3 of the GNU Lesser +General Public License, and the "GNU GPL" refers to version 3 of the GNU +General Public License. + + "The Library" refers to a covered work governed by this License, +other than an Application or a Combined Work as defined below. + + An "Application" is any work that makes use of an interface provided +by the Library, but which is not otherwise based on the Library. +Defining a subclass of a class defined by the Library is deemed a mode +of using an interface provided by the Library. + + A "Combined Work" is a work produced by combining or linking an +Application with the Library. The particular version of the Library +with which the Combined Work was made is also called the "Linked +Version". + + The "Minimal Corresponding Source" for a Combined Work means the +Corresponding Source for the Combined Work, excluding any source code +for portions of the Combined Work that, considered in isolation, are +based on the Application, and not on the Linked Version. + + The "Corresponding Application Code" for a Combined Work means the +object code and/or source code for the Application, including any data +and utility programs needed for reproducing the Combined Work from the +Application, but excluding the System Libraries of the Combined Work. + + 1. Exception to Section 3 of the GNU GPL. + + You may convey a covered work under sections 3 and 4 of this License +without being bound by section 3 of the GNU GPL. + + 2. Conveying Modified Versions. + + If you modify a copy of the Library, and, in your modifications, a +facility refers to a function or data to be supplied by an Application +that uses the facility (other than as an argument passed when the +facility is invoked), then you may convey a copy of the modified +version
[Pki-devel] [PATCH] 327 - small fix for SERVER_KEYGEN slot substitution
Addresses Ticket 2418 -
Some template substitution didn't happen during installation
(specifically SERVER_KEYGEN)
Please review,
Ade
From 27ffc1eb92232cba7816bdd50e8e8da288e6efad Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Fri, 29 Jul 2016 12:23:39 +0100
Subject: [PATCH] Do slot substitution for SERVER_KEYGEN
Ticket 2418
---
base/server/config/pkislots.cfg | 1 +
base/server/python/pki/server/deployment/pkiparser.py | 2 ++
2 files changed, 3 insertions(+)
diff --git a/base/server/config/pkislots.cfg b/base/server/config/pkislots.cfg
index 473b0da4e0b85bcd266cb64eebfc9b575c552f28..3873b83652e9fd0c9849dafcb1c50dcf5613e5c5 100644
--- a/base/server/config/pkislots.cfg
+++ b/base/server/config/pkislots.cfg
@@ -64,6 +64,7 @@ PKI_UNSECURE_PORT_SERVER_COMMENT_SLOT=[PKI_UNSECURE_PORT_SERVER_COMMENT]
PKI_USER_SLOT=[PKI_USER]
PKI_WEB_SERVER_TYPE_SLOT=[PKI_WEB_SERVER_TYPE]
PKI_WEBAPPS_NAME_SLOT=[PKI_WEBAPPS_NAME]
+SERVER_KEYGEN_SLOT=[SERVER_KEYGEN]
TOKENDB_HOST_SLOT=[TOKENDB_HOST]
TOKENDB_PORT_SLOT={TOKENDB_PORT]
TOKENDB_ROOT_SLOT=[TOKENDB_ROOT]
diff --git a/base/server/python/pki/server/deployment/pkiparser.py b/base/server/python/pki/server/deployment/pkiparser.py
index d940e2c94cdbe937ba15d4d8cedc756390013aa2..622f87e0753c264daf021490b98a72d2ee7eddcd 100644
--- a/base/server/python/pki/server/deployment/pkiparser.py
+++ b/base/server/python/pki/server/deployment/pkiparser.py
@@ -941,6 +941,8 @@ class PKIConfigParser:
"tomcat"
self.mdict['PKI_WEBAPPS_NAME_SLOT'] = \
"webapps"
+self.mdict['SERVER_KEYGEN_SLOT'] = \
+self.mdict['pki_enable_server_side_keygen']
self.mdict['TOMCAT_CFG_SLOT'] = \
self.mdict['pki_target_tomcat_conf']
self.mdict['TOMCAT_INSTANCE_COMMON_LIB_SLOT'] = \
--
2.4.3
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 326 - re-license the python client code
In order to keep the Dogtag plugin in the Openstack Barbican source tree, it is necessarily to re-license the Python client code to be LGPLv3 as opposed to GPLv2, to comply with Openstack rules for licensing of dependencies. http://governance.openstack.org/reference/licensing.html This patch makes the relevant changes. Please review. Thanks, AdeFrom 4b260467e28d62c17fddec5877a5c9c0bc91bf19 Mon Sep 17 00:00:00 2001 From: Ade Lee <a...@redhat.com> Date: Thu, 28 Jul 2016 10:36:50 +0100 Subject: [PATCH] Re-license the python client files to LGPLv3 --- base/common/LICENSE.LESSER | 170 + base/common/python/pki/__init__.py | 12 +-- base/common/python/pki/account.py | 12 +-- base/common/python/pki/authority.py| 12 +-- base/common/python/pki/cert.py | 12 +-- base/common/python/pki/cli/__init__.py | 12 +-- base/common/python/pki/cli/pkcs12.py | 12 +-- base/common/python/pki/client.py | 12 +-- base/common/python/pki/crypto.py | 12 +-- base/common/python/pki/feature.py | 12 +-- base/common/python/pki/key.py | 12 +-- base/common/python/pki/kra.py | 12 +-- base/common/python/pki/nssdb.py| 12 +-- base/common/python/pki/profile.py | 12 +-- base/common/python/pki/system.py | 12 +-- base/common/python/pki/systemcert.py | 12 +-- base/common/python/pki/upgrade.py | 12 +-- base/common/python/pki/util.py | 12 +-- base/common/python/setup.py| 16 ++-- 19 files changed, 280 insertions(+), 110 deletions(-) create mode 100644 base/common/LICENSE.LESSER diff --git a/base/common/LICENSE.LESSER b/base/common/LICENSE.LESSER new file mode 100644 index ..ca70b83cce4cdb9a5677aa43b5ff93d1865a --- /dev/null +++ b/base/common/LICENSE.LESSER @@ -0,0 +1,170 @@ +The Python client code is released under LGPLv3+. +This license is provided below: +** + + GNU LESSER GENERAL PUBLIC LICENSE + Version 3, 29 June 2007 + + Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + This version of the GNU Lesser General Public License incorporates +the terms and conditions of version 3 of the GNU General Public +License, supplemented by the additional permissions listed below. + + 0. Additional Definitions. + + As used herein, "this License" refers to version 3 of the GNU Lesser +General Public License, and the "GNU GPL" refers to version 3 of the GNU +General Public License. + + "The Library" refers to a covered work governed by this License, +other than an Application or a Combined Work as defined below. + + An "Application" is any work that makes use of an interface provided +by the Library, but which is not otherwise based on the Library. +Defining a subclass of a class defined by the Library is deemed a mode +of using an interface provided by the Library. + + A "Combined Work" is a work produced by combining or linking an +Application with the Library. The particular version of the Library +with which the Combined Work was made is also called the "Linked +Version". + + The "Minimal Corresponding Source" for a Combined Work means the +Corresponding Source for the Combined Work, excluding any source code +for portions of the Combined Work that, considered in isolation, are +based on the Application, and not on the Linked Version. + + The "Corresponding Application Code" for a Combined Work means the +object code and/or source code for the Application, including any data +and utility programs needed for reproducing the Combined Work from the +Application, but excluding the System Libraries of the Combined Work. + + 1. Exception to Section 3 of the GNU GPL. + + You may convey a covered work under sections 3 and 4 of this License +without being bound by section 3 of the GNU GPL. + + 2. Conveying Modified Versions. + + If you modify a copy of the Library, and, in your modifications, a +facility refers to a function or data to be supplied by an Application +that uses the facility (other than as an argument passed when the +facility is invoked), then you may convey a copy of the modified +version: + + a) under this License, provided that you make a good faith effort to + ensure that, in the event an Application does not supply the + function or data, the facility still operates, and performs + whatever part of its purpose remains meaningful, or + + b) under the GNU GPL, with none of the additional permissions of + this License applicable to that copy. + + 3. Object Code Incorporating Material from Library Header Files. + + The object code form of an Applicati
[Pki-devel] [DRAFT] general migration procedure to RHCS 9
Hi all, In CS 9.1, there are a number of mechanisms that have been added to allow administrators to migrate from RHCS8 -> CS 9.1. These have been detailed here: http://pki.fedoraproject.org/wiki/Migrating_a_CA_using_e xisting_CA_mechanism In CS 9.0, many of the same mechanisms do not exist. I have written a simple guide on how to do a migration in this case. http://pki.fedoraproject.org/wiki/Migrating_a_CA_using_general_mechanis m Please review and provide comments. Ade ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] Migration procedure from rhcs 8 to 9
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 ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 320 - pki-server db changes
With patch this time:
On Fri, 2016-06-03 at 08:59 -0400, Ade Lee wrote:
> commit 9450b5f7695cc827cced6e86281694daa1e5c2c8
> Author: Ade Lee <a...@redhat.com>
> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-develFrom 9450b5f7695cc827cced6e86281694daa1e5c2c8 Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Thu, 2 Jun 2016 09:41:35 -0400
Subject: [PATCH] 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
---
base/server/python/pki/server/__init__.py | 11 +-
base/server/python/pki/server/cli/db.py | 89 +++-
base/server/python/pki/server/cli/kra.py | 352 ++
3 files changed, 449 insertions(+), 3 deletions(-)
diff --git a/base/server/python/pki/server/__init__.py b/base/server/python/pki/server/__init__.py
index 47f6aa5b46af6cf38b231d94a88e6bb02c7d99b1..8347311cfe1692a500f21d86b0ac0c8261e1d752 100644
--- a/base/server/python/pki/server/__init__.py
+++ b/base/server/python/pki/server/__init__.py
@@ -318,7 +318,8 @@ class PKISubsystem(object):
def disable(self):
self.instance.undeploy(self.name)
-def open_database(self, name='internaldb'):
+def open_database(self, name='internaldb', bind_dn=None,
+ bind_password=None):
# TODO: add LDAPI support
hostname = self.config['%s.ldapconn.host' % name]
@@ -341,7 +342,13 @@ class PKISubsystem(object):
connection.set_security_database(self.instance.nssdb_dir)
auth_type = self.config['%s.ldapauth.authtype' % name]
-if auth_type == 'BasicAuth':
+if (bind_dn is not None and bind_password is not None):
+# connect using the provided credentials
+connection.set_credentials(
+bind_dn=bind_dn,
+bind_password=bind_password
+)
+elif auth_type == 'BasicAuth':
connection.set_credentials(
bind_dn=self.config['%s.ldapauth.bindDN' % name],
bind_password=self.instance.get_password(name)
diff --git a/base/server/python/pki/server/cli/db.py b/base/server/python/pki/server/cli/db.py
index 6cfd6b410eb75394f4b88b087b43a0538d3db6c6..709b39e2c576ffe60cfc04e71ebc9c3f3739bef5 100644
--- a/base/server/python/pki/server/cli/db.py
+++ b/base/server/python/pki/server/cli/db.py
@@ -23,6 +23,7 @@ from __future__ import print_function
import getopt
import ldap
import nss.nss as nss
+import subprocess
import sys
import pki.cli
@@ -35,6 +36,92 @@ class DBCLI(pki.cli.CLI):
'db', 'DB management commands')
self.add_module(DBUpgrade())
+self.add_module(DBSchemaUpgrade())
+
+
+class DBSchemaUpgrade(pki.cli.CLI):
+
+SCHEMA_PATH = '/usr/share/pki/server/conf/schema.ldif'
+
+def __init__(self):
+super(DBSchemaUpgrade, self).__init__(
+'schema-upgrade', 'Upgrade PKI database schema')
+
+def usage(self):
+print('Usage: pki-server db-schema-upgrade [OPTIONS]')
+print()
+print(' -i, --instanceInstance ID (default: pki-tomcat).')
+print(' -D, --bind-dn DN to connect to DB (default: cn=Directory Manager).')
+print(' -w, --bind-password Password to connect to DB.')
+print(' -v, --verbose Run in verbose mode.')
+print(' --help Show help message.')
+print()
+
+def execute(self, args):
+try:
+opts, _ = getopt.gnu_getopt(
+args, 'i:D:w:v', ['instance=', 'bind-dn=', 'bind-password=',
+ 'verbose', 'help'])
+
+except getopt.GetoptError as e:
+print('ERROR: ' + str(e))
+self.usa
[Pki-devel] [PATCH] 320 - pki-server db changes
commit 9450b5f7695cc827cced6e86281694daa1e5c2c8 Author: Ade Lee <a...@redhat.com> 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@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 303-306 Various issues
Patches 303, 305 and 306 have been modified as discussed and checked
in.
Patch 304 has been revised as discussed on IRC. Please review.
Ade
On Fri, 2016-05-20 at 17:00 -0500, Endi Sukma Dewata wrote:
> On 5/20/2016 2:20 PM, Ade Lee wrote:
> > Please review:
> >
> > Patches listed in reverse order (306 -> 303)
> >
> > Ade
>
> Some comments/questions:
>
> Patch #303:
> 1. Instead of using underscores (i.e. ca.publishing.cert_enable and
> ca.publishing.crl_enable) it would be more consistent to use dots
> (i.e.
> ca.publishing.cert.enable and ca.publishing.crl.enable) in the
> parameter
> names.
>
> 2. The PublisherProcessor.isCertPublishingEnabled() and
> isCRLPublishingEnabled() currently swallow the exception thrown by
> getBoolean() and interpret it as disabled. I think since "this should
> never happen" the exception should (if not too much additional work)
> be
> allowed to bubble up.
>
> Patch #304:
> 1. I think the default maxAge and maxFiles should not be unlimited
> because most people probably will use the default values until
> something
> goes wrong (e.g. disk full), and we want to avoid that. It would be
> better to pick something reasonable, for example 1 year and 100
> files,
> respectively.
>
> 2. Currently the unit for maxAge is hour. How long do people usually
> want to retain old files? Should we use day instead?
>
> 3. In purgeExcessFiles() the files are sorted by last modified
> timestamp. It's kind of risky since someone could accidentally do
> something that updates the timestamp, then code will be deleting a
> file
> that's not supposed to be purged yet. Can the files be sorted by
> their
> names? In Tomcat the log files can be sorted by their names since
> they
> contain a timestamp or sequence number.
>
> 4. Also in purgeExcessFiles() the last loop calls dir.listFiles() in
> each iteration. For efficiency it might be better to use a counter
> since
> the number of excess files can be computed before the loop.
>
> 5. The exception thrown by getInteger() should not be swallowed
> either.
> If there's a configuration problem we want to know that.
>
> Patch #305:
> 1. It might be better to check for invalid revocation reason in the
> RevocationReason.valueOf() itself so any code using it is guaranteed
> to
> get a valid value.
>
> Patch #306 will follow later.
> From 63f6047c3e535eb336689082101ca60e61a67f29 Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Thu, 19 May 2016 00:08:20 -0400
Subject: [PATCH] Add parameters to purge old published files
Ticket 2254
---
base/server/cms/src/CMakeLists.txt | 9 +-
.../cms/publish/publishers/FileBasedPublisher.java | 151 +++--
2 files changed, 150 insertions(+), 10 deletions(-)
diff --git a/base/server/cms/src/CMakeLists.txt b/base/server/cms/src/CMakeLists.txt
index d414d2859ba2512d1184b973a54e5807ff0c92fe..33b1cd3baf8d321c7f1a2f50e5f3e8360c515695 100644
--- a/base/server/cms/src/CMakeLists.txt
+++ b/base/server/cms/src/CMakeLists.txt
@@ -30,6 +30,13 @@ find_file(COMMONS_HTTPCLIENT_JAR
/usr/share/java
)
+find_file(COMMONS_IO_JAR
+NAMES
+commons-io.jar
+PATHS
+/usr/share/java
+)
+
find_file(COMMONS_LANG_JAR
NAMES
commons-lang.jar
@@ -124,7 +131,7 @@ javac(pki-cms-classes
com/netscape/cms/*.java
org/dogtagpki/server/*.java
CLASSPATH
-${COMMONS_CODEC_JAR} ${COMMONS_LANG_JAR} ${COMMONS_HTTPCLIENT_JAR}
+${COMMONS_CODEC_JAR} ${COMMONS_IO_JAR} ${COMMONS_LANG_JAR} ${COMMONS_HTTPCLIENT_JAR}
${HTTPCLIENT_JAR} ${HTTPCORE_JAR}
${XALAN_JAR} ${XERCES_JAR}
${JSS_JAR} ${SYMKEY_JAR}
diff --git a/base/server/cms/src/com/netscape/cms/publish/publishers/FileBasedPublisher.java b/base/server/cms/src/com/netscape/cms/publish/publishers/FileBasedPublisher.java
index c48aa2db44163850d34f99e146ba6505926d2389..f3fa7eceed33697823baf89f7dcc751e0b43494f 100644
--- a/base/server/cms/src/com/netscape/cms/publish/publishers/FileBasedPublisher.java
+++ b/base/server/cms/src/com/netscape/cms/publish/publishers/FileBasedPublisher.java
@@ -19,6 +19,7 @@ package com.netscape.cms.publish.publishers;
import java.io.ByteArrayOutputStream;
import java.io.File;
+import java.io.FileFilter;
import java.io.FileOutputStream;
import java.io.FilterOutputStream;
import java.io.IOException;
@@ -28,14 +29,17 @@ import java.security.cert.CRLException;
import java.security.cert.CertificateEncodingException;
import java.security.cert.X509CRL;
import java.security.cert.X509Certificate;
+import java.text.ParseException;
+import java.util.Arrays;
import java.util.Locale;
import java.util.TimeZone;
import java.util.Vector;
+import java.util.reg
[Pki-devel] [PATCH] 303-306 Various issues
Please review:
Patches listed in reverse order (306 -> 303)
Ade
commit e3d47aabee97773832d2f8ac7ff138314b44f646
Author: Ade Lee <a...@redhat.com>
Date: Thu May 19 11:56:26 2016 -0400
Add revocation information to pki CLI output.
The date on which the certificate is revoked and the agent that
revoked it is displayed now in cert-find and cert-show output.
Ticket 1055
commit fb7707dbf7148387075fc21d803e2ecb12c66ab6
Author: Ade Lee <a...@redhat.com>
Date: Thu May 19 10:49:59 2016 -0400
Allow cert-find using revocation reasons
The REST API expects the integer revocation code to be passed
in a certificate search. We have modified the client to allow
the user to provide either a revocation code or a revocation
reason as a search parameter.
Ticket 1053
commit 443b3676302e7861180802784d8a1ebc43d07ea3
Author: Ade Lee <a...@redhat.com>
Date: Thu May 19 00:08:20 2016 -0400
Add parameters to purge old published files
Ticket 2254
commit 31342868aa4468fd7c2818727930932fd1e2d23e
Author: Ade Lee <a...@redhat.com>
Date: Wed May 18 15:33:36 2016 -0400
Add parameters to disable cert or crl publishing
Right now, if publishing is enabled, both CRLs and Cert publishing
is enabled. This causes a bunch of spurious error messages on
IPA servers as cert publishing is not configured.
As it is impossible to determine if cert publishing is not desired
or simply misconfigured, we provide options to explicitly disable
either cert or crl publishing.
Specifically:
* to enable/disable both cert and crl publishing:
ca.publishing.enable = True/False
This is the legacy behavior.
* to enable CRL publishing only:
ca.publishing.enable = True
ca.publishing.cert_enable = False
* to enable cert publishing only:
ca.publishing.enable = True
ca.publishing.crl_enable = False
Ticket 2275From e3d47aabee97773832d2f8ac7ff138314b44f646 Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Thu, 19 May 2016 11:56:26 -0400
Subject: [PATCH 306/306] Add revocation information to pki CLI output.
The date on which the certificate is revoked and the agent that
revoked it is displayed now in cert-find and cert-show output.
Ticket 1055
---
.../org/dogtagpki/server/ca/rest/CertService.java | 24 +--
.../src/com/netscape/certsrv/cert/CertData.java| 36 ++
.../com/netscape/certsrv/cert/CertDataInfo.java| 33
.../src/com/netscape/cmstools/cert/CertCLI.java| 21 +
4 files changed, 105 insertions(+), 9 deletions(-)
diff --git a/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java b/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
index 2c5fa52b8e13f8c9bc033b9bc9a850e6220cef33..54a349e2a60c6fd7571c2cb43a0504d96050c11a 100644
--- a/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
+++ b/base/ca/src/org/dogtagpki/server/ca/rest/CertService.java
@@ -41,15 +41,6 @@ import javax.ws.rs.core.Request;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.UriInfo;
-import netscape.security.pkcs.ContentInfo;
-import netscape.security.pkcs.PKCS7;
-import netscape.security.pkcs.SignerInfo;
-import netscape.security.provider.RSAPublicKey;
-import netscape.security.x509.AlgorithmId;
-import netscape.security.x509.RevocationReason;
-import netscape.security.x509.X509CertImpl;
-import netscape.security.x509.X509Key;
-
import org.apache.catalina.realm.GenericPrincipal;
import org.jboss.resteasy.plugins.providers.atom.Link;
@@ -84,6 +75,15 @@ import com.netscape.cms.servlet.processors.CAProcessor;
import com.netscape.cmsutil.ldap.LDAPUtil;
import com.netscape.cmsutil.util.Utils;
+import netscape.security.pkcs.ContentInfo;
+import netscape.security.pkcs.PKCS7;
+import netscape.security.pkcs.SignerInfo;
+import netscape.security.provider.RSAPublicKey;
+import netscape.security.x509.AlgorithmId;
+import netscape.security.x509.RevocationReason;
+import netscape.security.x509.X509CertImpl;
+import netscape.security.x509.X509Key;
+
/**
* @author alee
*
@@ -527,6 +527,9 @@ public class CertService extends PKIService implements CertResource {
Date notAfter = cert.getNotAfter();
if (notAfter != null) certData.setNotAfter(notAfter.toString());
+certData.setRevokedOn(record.getRevokedOn());
+certData.setRevokedBy(record.getRevokedBy());
+
certData.setStatus(record.getStatus());
if (authority.noncesEnabled() && generateNonce) {
@@ -575,6 +578,9 @@ public class CertService extends PKIService implements CertResource {
info.setIssuedOn(record.getCreateTime());
info.setIssuedBy(record.getIssuedBy());
+info.setRevokedOn(record.getRevokedOn());
+info.setRevokedBy(record.getRevokedBy());
+
URI uri = uriInfo.getBaseUriBuilder().
Re: [Pki-devel] [PATCH] fix for existing CA for HSM
Acked by Endi. Pushed to master. On Wed, 2016-05-11 at 23:11 -0400, Ade Lee wrote: > commit 5efd691e71f32b350737d95fe08f470164e60192 > Author: Ade Lee <a...@redhat.com> > Date: Thu May 12 00:35:41 2016 +0200 > > Fix existing ca setup to work with HSM > > If the existing CA keys are in an HSM, the code fails to > load the keys becauseit does not take into account the full > nickname. > This small fix addresses this bug. > > Please review, > Thanks, > Ade > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0106..0107 Add issuer DN to cert search params/result
ACK. Is the new search parameter added to the CLI (either python or Java?) or displayed in cert info results from the CLI? How are these changes tested? Ade On Tue, 2016-05-10 at 13:49 +1000, Fraser Tweedale wrote: > Hi team, > > The attached patches add a search parameter for issuer DN, and > include the issuer DN in the search results. > > Cheers, > Fraser > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] patches for authz realm and fixing output on request rejection
Thanks. Fixed as below. Pushed to master.
On Mon, 2016-05-09 at 17:51 -0500, Endi Sukma Dewata wrote:
> On 5/9/2016 2:18 PM, Ade Lee wrote:
> > Patch descriptions .. in reverse order.
> >
> > Note that the CA setup for authz is further documented at
> > pki.fedoraproject.org/wiki/Kra_authz_realm , where I have added a
> > section on 'CA Configuration".
> >
> > Thanks,
> > Ade
> >
> > ****
> > commit ad1fcecc2f36cc1ebc1f13efe3df9d1e138224b7
> > Author: Ade Lee <a...@redhat.com>
> > Date: Mon May 9 15:00:20 2016 -0400
> >
> > Add authz realm check for cert enrollment
> >
> > Ticket 2041
> >
> > commit b5232ce101083409ed9a86e9057620cca7288f62
> > Author: Ade Lee <a...@redhat.com>
> > Date: Sat May 7 00:06:08 2016 -0400
> >
> > Fix error output when request is rejected
> >
> > With this fix, error messages are returned to the user when
> > a request is rejected - either in the UI or from the pki CLI.
> >
> > Trac Ticket 1247 (amongst others)
> >
> > commit 82d18a99103de1fa749b077cfccec5ff65ceb4a5
> > Author: Ade Lee <a...@redhat.com>
> > Date: Wed May 4 18:25:51 2016 -0400
> >
> > Add realm to requests coming in from CA
> >
> > Requests to the KRA through the CA-KRA connector use the
> > Enrollment
> > Service. This has been modified to read and store any realm
> > passed in.
> > The realm can be added to the request by havibg the admin add
> > a AuthzRealmDefault and AuthzRealmConstraint in a profile.
> >
> > At this point, all the constraint does is verify that the
> > realm is
> > one of a specified list of realms. More verification will be
> > added
> > in a subsequent patch.
> >
> > No attempt is made yet to allow users to specify the realm.
> > This
> > would need to be added as a ProfileInput.
> >
> > Part of Ticket 2041
>
> ACK. Just some comments:
>
> 1. In AuthzRealmDefault.populate() we should wrap and rethrow the
> exception instead of ignoring it.
>
> 2. In UserMessages.properties let's use "Authorization" instead of
> "Authz" to be more user-friendly. Or just "Realm" instead of "Authz
> realm".
>
> 3. In HttpPKIMessage.fromRequest() we probably want to copy the realm
> without any condition (e.g. to copy the null value).
>
> reqRealm = r.getRealm();
>
> 4. In CertRequestInfoFactory.create() this if condition is redundant:
>
> if (error != null) {
> info.setErrorMessage(error);
> }
>
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 302 - migration script for registry.cfg for realm
Migration script to add entries for new constraints and defaults
for authz realm changes.
Please review,
Thanks,
Ade
From 8dd438fe42060e29cbe4d6d55f81ff1c1b31d9b4 Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Mon, 9 May 2016 17:24:29 -0400
Subject: [PATCH] Add migration script ofr realm changes in registry.cfg
Part of Ticket 2041
---
.../upgrade/10.3.0/02-AddAuthzRealmToRegistry | 80 ++
1 file changed, 80 insertions(+)
create mode 100644 base/server/upgrade/10.3.0/02-AddAuthzRealmToRegistry
diff --git a/base/server/upgrade/10.3.0/02-AddAuthzRealmToRegistry b/base/server/upgrade/10.3.0/02-AddAuthzRealmToRegistry
new file mode 100644
index ..f80de37585e1d7da3a358b6dff5b24f8ed25d960
--- /dev/null
+++ b/base/server/upgrade/10.3.0/02-AddAuthzRealmToRegistry
@@ -0,0 +1,80 @@
+#!/usr/bin/python
+# Authors:
+# Ade Lee <a...@redhat.com>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; version 2 of the License.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# Copyright (C) 2016 Red Hat, Inc.
+# All rights reserved.
+
+from __future__ import absolute_import
+import os.path
+import pki.server.upgrade
+
+
+class AddAuthzRealmToRegistry(pki.server.upgrade.PKIServerUpgradeScriptlet):
+
+new_config = {
+'defaultPolicy.authzRealmDefaultImpl.class':
+'com.netscape.cms.profile.def.AuthzRealmDefault',
+'defaultPolicy.authzRealmDefaultImpl.desc':
+'Authz Realm Default',
+'defaultPolicy.authzRealmDefaultImpl.name':
+'Authz Realm Default',
+'constraintPolicy.authzRealmConstraintImpl.class':
+'com.netscape.cms.profile.constraint.AuthzRealmConstraint',
+'constraintPolicy.authzRealmConstraintImpl.desc':
+'Authz Realm Constraint',
+'constraintPolicy.authzRealmConstraintImpl.name':
+'Authz Realm Constraint'
+}
+
+constraint_name = 'authzRealmConstraintImpl'
+
+default_name = 'authzRealmDefaultImpl'
+
+def __init__(self):
+super(AddAuthzRealmToRegistry, self).__init__()
+self.message = 'Add authz realm constraint and default to registry'
+
+def upgrade_subsystem(self, instance, subsystem):
+if subsystem.name == 'ca':
+self.add_new_entries(instance, subsystem)
+
+def add_new_entries(self, instance, subsystem): # pylint: disable=W0613
+filename = os.path.join(subsystem.conf_dir, 'registry.cfg')
+self.backup(filename)
+
+properties = pki.PropertyFile(filename)
+properties.read()
+
+for k, v in self.new_config.items():
+existing_value = properties.get(k)
+if existing_value is not None:
+continue
+properties.set(k, v)
+
+# add constraint to constraint list
+constraints = properties.get('constraintPolicy.ids').split(',')
+if self.constraint_name not in constraints:
+constraints.append(self.constraint_name)
+properties.set('constraintPolicy.ids', ','.join(constraints))
+
+# add default to default list
+defaults = properties.get('defaultPolicy.ids').split(',')
+if self.default_name not in defaults:
+defaults.append(self.default_name)
+properties.set('defaultPolicy.ids', ','.join(defaults))
+
+properties.write()
--
2.4.3
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0105 Add pki-server ca-cert-db-upgrade command
Isn't all this predicated on a schema change that adds the issuer as an optional field for the certRecord? Ade On Mon, 2016-05-09 at 17:15 +1000, Fraser Tweedale wrote: > Hi all, > > The following patch adds a pki-server subcommand for updating > certificate records to add the issuerName attribute. > > It is for #1667 (Database upgrade script to add issuerName attribute > to all cert entries). > > Follow-up question: should I (and if so, how should I) also add an > upgrade scriptlet to perform the upgrade for Dogtag CA subsystem on > the host? Is there a precedent for invoking pki-server (or > subroutines thereof) from pki-server-upgrade scriptlets? > > Cheers, > Fraser > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] patches for authz realm and fixing output on request rejection
Patch descriptions .. in reverse order. Note that the CA setup for authz is further documented at pki.fedoraproject.org/wiki/Kra_authz_realm , where I have added a section on 'CA Configuration". Thanks, Ade commit ad1fcecc2f36cc1ebc1f13efe3df9d1e138224b7 Author: Ade Lee <a...@redhat.com> Date: Mon May 9 15:00:20 2016 -0400 Add authz realm check for cert enrollment Ticket 2041 commit b5232ce101083409ed9a86e9057620cca7288f62 Author: Ade Lee <a...@redhat.com> Date: Sat May 7 00:06:08 2016 -0400 Fix error output when request is rejected With this fix, error messages are returned to the user when a request is rejected - either in the UI or from the pki CLI. Trac Ticket 1247 (amongst others) commit 82d18a99103de1fa749b077cfccec5ff65ceb4a5 Author: Ade Lee <a...@redhat.com> Date: Wed May 4 18:25:51 2016 -0400 Add realm to requests coming in from CA Requests to the KRA through the CA-KRA connector use the Enrollment Service. This has been modified to read and store any realm passed in. The realm can be added to the request by havibg the admin add a AuthzRealmDefault and AuthzRealmConstraint in a profile. At this point, all the constraint does is verify that the realm is one of a specified list of realms. More verification will be added in a subsequent patch. No attempt is made yet to allow users to specify the realm. This would need to be added as a ProfileInput. Part of Ticket 2041From 82d18a99103de1fa749b077cfccec5ff65ceb4a5 Mon Sep 17 00:00:00 2001 From: Ade Lee <a...@redhat.com> Date: Wed, 4 May 2016 18:25:51 -0400 Subject: [PATCH 299/301] Add realm to requests coming in from CA Requests to the KRA through the CA-KRA connector use the Enrollment Service. This has been modified to read and store any realm passed in. The realm can be added to the request by havibg the admin add a AuthzRealmDefault and AuthzRealmConstraint in a profile. At this point, all the constraint does is verify that the realm is one of a specified list of realms. More verification will be added in a subsequent patch. No attempt is made yet to allow users to specify the realm. This would need to be added as a ProfileInput. Part of Ticket 2041 --- base/ca/shared/conf/registry.cfg | 6 ++ base/ca/src/com/netscape/ca/CAService.java | 64 ++-- .../netscape/certsrv/connector/IPKIMessage.java| 6 ++ .../src/com/netscape/kra/EnrollmentService.java| 29 +++--- base/kra/src/com/netscape/kra/KRAService.java | 3 +- .../profile/constraint/AuthzRealmConstraint.java | 109 + .../cms/profile/def/AuthzRealmDefault.java | 93 ++ .../cms/servlet/connector/ConnectorServlet.java| 30 +++--- base/server/cmsbundle/src/UserMessages.properties | 6 ++ .../netscape/cmscore/connector/HttpPKIMessage.java | 13 +++ 10 files changed, 303 insertions(+), 56 deletions(-) create mode 100644 base/server/cms/src/com/netscape/cms/profile/constraint/AuthzRealmConstraint.java create mode 100644 base/server/cms/src/com/netscape/cms/profile/def/AuthzRealmDefault.java diff --git a/base/ca/shared/conf/registry.cfg b/base/ca/shared/conf/registry.cfg index 9cd4e6d5c89b6e9bd0323fd3fd272b4af1de9568..8e62939725e380ae247fab83d602970dc65bdebb 100644 --- a/base/ca/shared/conf/registry.cfg +++ b/base/ca/shared/conf/registry.cfg @@ -3,6 +3,9 @@ constraintPolicy.ids=noConstraintImpl,subjectNameConstraintImpl,uniqueSubjectNam constraintPolicy.signingAlgConstraintImpl.class=com.netscape.cms.profile.constraint.SigningAlgConstraint constraintPolicy.signingAlgConstraintImpl.desc=Signing Algorithm Constraint constraintPolicy.signingAlgConstraintImpl.name=Signing Algorithm Constraint +constraintPolicy.authzRealmConstraintImpl.class=com.netscape.cms.profile.constraint.AuthzRealmConstraint +constraintPolicy.authzRealmConstraintImpl.desc=Authz Realm Constraint +constraintPolicy.authzRealmConstraintImpl.name=Authz Realm Constraint constraintPolicy.extensionConstraintImpl.class=com.netscape.cms.profile.constraint.ExtensionConstraint constraintPolicy.extensionConstraintImpl.desc=Extension Constraint constraintPolicy.extensionConstraintImpl.name=Extension Constraint @@ -76,6 +79,9 @@ defaultPolicy.userSigningAlgDefaultImpl.name=User Supplied Signing Alg Default defaultPolicy.signingAlgDefaultImpl.class=com.netscape.cms.profile.def.SigningAlgDefault defaultPolicy.signingAlgDefaultImpl.desc=Signing Algorithm Default defaultPolicy.signingAlgDefaultImpl.name=Signing Algorithm Default +defaultPolicy.authzRealmDefaultImpl.class=com.netscape.cms.profile.def.AuthzRealmDefault +defaultPolicy.authzRealmDefaultImpl.desc=Authz Realm Default +defaultPolicy.authzRealmDefaultImpl.name=Authz Realm Default defaultPolicy.authorityKeyI
Re: [Pki-devel] [PATCH] 297, 298 add validity check for external CA
On Fri, 2016-04-22 at 16:37 -0500, Endi Sukma Dewata wrote:
> On 4/22/2016 2:37 PM, Ade Lee wrote:
> > commit 0fe7bf5ff989bbc24875dce30cec8f32e89c0a8f
> > Author: Ade Lee <a...@redhat.com>
> > Date: Fri Apr 22 15:31:43 2016 -0400
> >
> > Add validity check for the signing certificate in pkispawn
> >
> > When either an existing CA or external CA installation is
> > performed, use the pki-server cert validation tool to check
> > the signing certiticate and chain.
> >
> > Ticket #2043
> >
> > commit 9104fdda145c4f2bbbedec7256c73922e8bffcef
> > Author: Ade Lee <a...@redhat.com>
> > Date: Wed Apr 20 17:26:23 2016 -0400
> >
> > Add CLI to check system certificate status
> >
> > We add two different calls:
> > 1. pki client-cert-validate - which checks a certificate in
> > the client
> > certdb and calls the System cert verification call
> > performed by JSS
> >in the system self test. This does some basic extensions
> > and trust
> >tests, and also validates cert validity and cert trust
> > chain.
> >
> > 2. pki-server subsystem-cert-validate
> > This calls pki client-cert-validate using the nssdb for the
> > subsystem
> > on all of the system certificates by default (or just one
> > if the
> > nickname is defined).
> >
> > This is a great thing to call when healthchecking an
> > instance,
> > and also will be used by pkispawn to verify the signing
> > cert in the
> > externally signed CA case.
> >
> > Trac Ticket 2043
> >
>
> In general it's ACKed. I have some minor comments/questions:
>
> 1. The SubsystemCertificateVerifier probably should be renamed to
> SystemCertificateVerifier since "system certificate" refers to a cert
> in
> the subsystem/instance's NSS database and "subsystem certificate"
> could
> be confused with the "subsystemCert cert-pki-tomcat".
>
done
> 2. Instead of storing a shared SubsystemCertificateVerifier object in
> the PKIDeployer object it might be better to create a factory method,
> so
> the verifier can be used like this:
>
>verifier = deployer.create_system_cert_verifier()
>verifier.verify_certificate('signing')
>
> That way the life-cycle of the verifier object will be short.
>
done
> 3. The .classpath got changed to point to a local path on your
> machine.
>
done
> 4. Is the "hardward-" name used consistently in our code?
>
>passwd = instance.get_password("hardware-%s" % token)
>
it should be for non-internal.From 537828983b11d1b26c5b1b140e79eaa45a06c63a Mon Sep 17 00:00:00 2001
From: Ade Lee <a...@redhat.com>
Date: Fri, 22 Apr 2016 15:31:43 -0400
Subject: [PATCH 2/2] Add validity check for the signing certificate in
pkispawn
When either an existing CA or external CA installation is
performed, use the pki-server cert validation tool to check
the signing certiticate and chain.
Ticket #2043
---
.../python/pki/server/deployment/pkihelper.py | 32 ++
.../server/deployment/scriptlets/configuration.py | 51 +++---
2 files changed, 68 insertions(+), 15 deletions(-)
diff --git a/base/server/python/pki/server/deployment/pkihelper.py b/base/server/python/pki/server/deployment/pkihelper.py
index f01f6f69ff66d3687875c8f3d88840daf2115e3f..2898d7fe072883ca37bda0ffdbe5965c680ceb36 100644
--- a/base/server/python/pki/server/deployment/pkihelper.py
+++ b/base/server/python/pki/server/deployment/pkihelper.py
@@ -4592,6 +4592,34 @@ class ConfigClient:
return cert
+class SystemCertificateVerifier:
+""" Verifies system certificates for a subsystem"""
+
+def __init__(self, instance=None, subsystem=None):
+self.instance = instance
+self.subsystem = subsystem
+
+def verify_certificate(self, cert_id=None):
+cmd = ['pki-server', 'subsystem-cert-validate',
+ '-i', self.instance.name,
+ self.subsystem]
+if cert_id is not None:
+cmd.append(cert_id)
+try:
+subprocess.check_output(
+cmd,
+stderr=subprocess.STDOUT)
+except subprocess.CalledProcessError as e:
+config.pki_log.error(
+"pki subsystem-cert-validate return code: " + str(e.returncode),
+extra=config.PKI_INDENTATION_LEVEL_2
+)
+config.pki_log.error(
+e.output,
+extra=config.PKI_INDENTATION_LEVEL_2)
+raise
+
+
class PKIDeployer:
"&quo
Re: [Pki-devel] [PATCH] 285 - 293 Patches for fine grained authz in the KRA
Thanks, Pushed to master. On Wed, 2016-04-20 at 15:23 -0500, Endi Sukma Dewata wrote: > On 4/19/2016 9:47 PM, Ade Lee wrote: > > Some comments inline, although most of this was discussed on #irc. > > > > I have added two additional patches which are to be applied on top > > of 258=293. > > > > 294: This patch fixes the problems identified in this review. In > > particular: > > > > Review comments addressed: > > 1. when archiving or generating keys, realm is checked > > 2. when no plugin is found for a realm, access is denied. > > 3. rename mFoo to foo for new variables. > > 4. add chaining of exceptions > > 5. remove attributes from KeyArchivalRequest etc. when realm > > is > > null > > 6. Add more detail to denial in BasicGroupAuthz > > > > 295 - Adds the ability for authz plugins to support multiple > > realms. > > In particular, the authorize() command has been extended to > > allow > > the realm to be passed in, and the ACL plugins have been > > modified > > to account for the realm. > > > > Please review, > > ACK. > ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 297, 298 add validity check for external CA
commit 0fe7bf5ff989bbc24875dce30cec8f32e89c0a8f Author: Ade Lee <a...@redhat.com> Date: Fri Apr 22 15:31:43 2016 -0400 Add validity check for the signing certificate in pkispawn When either an existing CA or external CA installation is performed, use the pki-server cert validation tool to check the signing certiticate and chain. Ticket #2043 commit 9104fdda145c4f2bbbedec7256c73922e8bffcef Author: Ade Lee <a...@redhat.com> Date: Wed Apr 20 17:26:23 2016 -0400 Add CLI to check system certificate status We add two different calls: 1. pki client-cert-validate - which checks a certificate in the client certdb and calls the System cert verification call performed by JSS in the system self test. This does some basic extensions and trust tests, and also validates cert validity and cert trust chain. 2. pki-server subsystem-cert-validate This calls pki client-cert-validate using the nssdb for the subsystem on all of the system certificates by default (or just one if the nickname is defined). This is a great thing to call when healthchecking an instance, and also will be used by pkispawn to verify the signing cert in the externally signed CA case. Trac Ticket 2043From 0fe7bf5ff989bbc24875dce30cec8f32e89c0a8f Mon Sep 17 00:00:00 2001 From: Ade Lee <a...@redhat.com> Date: Fri, 22 Apr 2016 15:31:43 -0400 Subject: [PATCH 298/298] Add validity check for the signing certificate in pkispawn When either an existing CA or external CA installation is performed, use the pki-server cert validation tool to check the signing certiticate and chain. Ticket #2043 --- .../python/pki/server/deployment/pkihelper.py | 29 + .../server/deployment/scriptlets/configuration.py | 50 +++--- 2 files changed, 64 insertions(+), 15 deletions(-) diff --git a/base/server/python/pki/server/deployment/pkihelper.py b/base/server/python/pki/server/deployment/pkihelper.py index f01f6f69ff66d3687875c8f3d88840daf2115e3f..2c7ab0ef143839159887f595e9e9577f3fe0647d 100644 --- a/base/server/python/pki/server/deployment/pkihelper.py +++ b/base/server/python/pki/server/deployment/pkihelper.py @@ -4592,6 +4592,34 @@ class ConfigClient: return cert +class SubsystemCertificateVerifier: +""" Verifies system certificates for a subsystem""" + +def __init__(self, instance=None, subsystem=None): +self.instance = instance +self.subsystem = subsystem + +def verify_certificate(self, cert_id=None): +cmd = ['pki-server', 'subsystem-cert-validate', + '-i', self.instance.name, + self.subsystem] +if cert_id is not None: +cmd.append(cert_id) +try: +subprocess.check_output( +cmd, +stderr=subprocess.STDOUT) +except subprocess.CalledProcessError as e: +config.pki_log.error( +"pki subsystem-cert-validate return code: " + str(e.returncode), +extra=config.PKI_INDENTATION_LEVEL_2 +) +config.pki_log.error( +e.output, +extra=config.PKI_INDENTATION_LEVEL_2) +raise + + class PKIDeployer: """Holds the global dictionaries and the utility objects""" @@ -4621,6 +4649,7 @@ class PKIDeployer: self.systemd = Systemd(self) self.tps_connector = TPSConnector(self) self.config_client = ConfigClient(self) +self.subsystem_cert_verifier = SubsystemCertificateVerifier(self) def deploy_webapp(self, name, doc_base, descriptor): """ diff --git a/base/server/python/pki/server/deployment/scriptlets/configuration.py b/base/server/python/pki/server/deployment/scriptlets/configuration.py index 5f77ac52379be0ca08b1a5dff9f71626c731bd3f..42d6b401224a76c036307b33b2d1febd5400f452 100644 --- a/base/server/python/pki/server/deployment/scriptlets/configuration.py +++ b/base/server/python/pki/server/deployment/scriptlets/configuration.py @@ -88,7 +88,8 @@ class PkiScriptlet(pkiscriptlet.AbstractBasePkiScriptlet): instance = pki.server.PKIInstance(deployer.mdict['pki_instance_name']) instance.load() -subsystem = instance.get_subsystem(deployer.mdict['pki_subsystem'].lower()) +subsystem = instance.get_subsystem( +deployer.mdict['pki_subsystem'].lower()) token = deployer.mdict['pki_token_name'] nssdb = instance.open_nssdb(token) @@ -146,7 +147,8 @@ class PkiScriptlet(pkiscriptlet.AbstractBasePkiScriptlet): with open(external_csr_path) as f: signing_csr = f.read() -signing_csr = pki.nssdb.convert_csr(signing_csr, 'pem', 'base64') +signing_csr = pki.nssdb.co
Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication support
ACK on latest 96 and 99. I will ask cfu or jmagne to look at the KeyRetrieveRunner logic today. Ade On Thu, 2016-04-21 at 14:58 +1000, Fraser Tweedale wrote: > Thanks Ade. Updated patch 0096 attached. Comments inline. > > On Wed, Apr 20, 2016 at 11:30:52AM -0400, Ade Lee wrote: > > Comments: > > > > 95 - ack > > > > 96 - > > > > 1. You have made the return type of initSigUnit() to be boolean. > > Should you be checking the return value in init()? > > > It is not needed to check it here; only when re-entering init from > the KeyReplicatorRunner thread. > > > 2. In addInstanceToAuthorityKeyHosts(), you are still using only > > the > > hostname. Should be host:port > > > Good pickup. Fixed in latest patch. > > > 3. The logic in the KeyRetrieverRunner class looks OK to me, but > > I'd > > like cfu and/or jmagne to check it and make sure we are calling the > > right primitives to wrap/unwrap inside the cryptographic token. > > > > Also I'd like them to confirm that this would wor for an HSM. > > Statements like the following make me question that: > >CryptoToken token = manager.getInternalKeyStorageToken() > > > It won't work on HSM. Can I get an HSM to test with? ;) I've filed > a ticket for HSM support[1]. FreeIPA does not yet support HSM[2] so > I think we can put it in 10.4 milestone (I've put it there for now). > > [1] https://fedorahosted.org/pki/ticket/2292 > [2] https://fedorahosted.org/freeipa/ticket/5608 > > > 4. Can you explain what happens if for some reason the script fails > > to > > retrieve the key? Do we end up retrying later and if so, when? > > > If the script fails to retrieve the key, it does not retry > automatically. I filed a ticket[3] to implement retry with > backoff (this patchset is big enough already!) and put it in > 10.3.1 milestone (that's up for discussion). > > [3] https://fedorahosted.org/pki/ticket/2293 > > Right now, the following events cause authority reinitialisation, > entailing key retrieval if necessary: > > - Dogtag is restarted > - LDAP disconnect-reconnect > - LDAP modification of authority replicated from another clone > > > 97- ACK > > > > 98 - ACK > > > Thanks. Any feedback on patch 0099? ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication support
Comments: 95 - ack 96 - 1. You have made the return type of initSigUnit() to be boolean. Should you be checking the return value in init()? 2. In addInstanceToAuthorityKeyHosts(), you are still using only the hostname. Should be host:port 3. The logic in the KeyRetrieverRunner class looks OK to me, but I'd like cfu and/or jmagne to check it and make sure we are calling the right primitives to wrap/unwrap inside the cryptographic token. Also I'd like them to confirm that this would wor for an HSM. Statements like the following make me question that: CryptoToken token = manager.getInternalKeyStorageToken() 4. Can you explain what happens if for some reason the script fails to retrieve the key? Do we end up retrying later and if so, when? 97- ACK 98 - ACK On Wed, 2016-04-20 at 16:15 +1000, Fraser Tweedale wrote: > New version of 0097 attached (0097-4). The only change is some > minor improvements to the pki-ipa-retrieve-key Python program. > > Cheers, > Fraser > > On Tue, Apr 19, 2016 at 07:32:16PM +1000, Fraser Tweedale wrote: > > Both issues addressed in latest patchset. Two new patches in the > > mix; the order is: > > > > 0095-4, 0098, 0099, 0096-4, 0097-3 (tip) > > > > I also added another attribute to schema for the authority > > certificate serial number. It is not used in current code but I > > have a hunch it may be needed for renewal, so I'm adding it now. > > > > Thanks, > > Fraser > > > > On Thu, Apr 14, 2016 at 05:34:45PM -0400, Ade Lee wrote: > > > Couple of points on 96/97. > > > > > > 1. First off, I'm not sure you followed my concern about being > > > able to > > > distinguish between CA instances. > > > > > > On an IPA system, this is not an issue because there is only one > > > CA on > > > the server. In this case, I imagine there will be a well known > > > directory which custodia would work with. > > > > > > In general though, we have to imagine that someone could end up > > > installing two different dogtag ca instances on the same server. > > > CMS.getEEHost() would result in the same value (the hostname) > > > for both > > > CAs. How does your helper program (or custodia) know which key > > > to > > > retrieve? > > > > > > The way to distinguish Dogtag instances is host AND port. > > > > > > 2. So, we're very careful that the signing keys are never in > > > memory in > > > the server. All accesses to the system certs are through JSS/NSS > > > which > > > essentially provides us handles to the keys. > > > > > > Now, I see a case where we import PKCS12 data AND the password > > > into > > > memory, so that we can import it into NSS? Say it ain't so .. > > > > > > With custodia, we have a secure mechanism of transferring the > > > keys from > > > one server to another. It makes more sense to me to have the > > > server > > > kick off the custodia transfer and then have that process also > > > import > > > into the NSS db. The server would then need to await status from > > > the > > > custodia/retriever process - and then initialize the signing unit > > > from > > > the NSS DB. Or am I completely confused? > > > > > > Ade > > > > > > > > > > > > On Thu, 2016-04-14 at 16:35 -0400, Ade Lee wrote: > > > > Still reviewing .. ACK on 87-95 (inclusive). > > > > > > > > On Thu, 2016-04-14 at 16:18 +1000, Fraser Tweedale wrote: > > > > > On Thu, Apr 14, 2016 at 09:04:31AM +1000, Fraser Tweedale > > > > > wrote: > > > > > > On Wed, Apr 13, 2016 at 05:26:44PM -0400, Ade Lee wrote: > > > > > > > Still reviewing .. > > > > > > > > > > > > > > See comment on 87. ACK on 88,89,90,91,92,93, 94, 95. > > > > > > > > > > > > > > Ade > > > > > > > > > > > > > > On Mon, 2016-04-11 at 12:32 +1000, Fraser Tweedale wrote: > > > > > > > > Thanks for review, Ade. Comments to specific feedback > > > > > > > > inline. > > > > > > > > Rebased and updated patches attached. The substantive > > > > > > > > changes > > > > > > > > are: > > > > > > > > > > > > > > > > - KeyRetriever implementations are now required NOT to > > > > > >
Re: [Pki-devel] [PATCH] 717 Fixed PKCS #12 export options.
ACK On Mon, 2016-04-18 at 11:38 -0500, Endi Sukma Dewata wrote: > The CLIs for exporting PKCS #12 file have been modified to accept > options to export without trust flags, keys, and/or certificate > chain. > > https://fedorahosted.org/pki/ticket/1736 > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 285 - 293 Patches for fine grained authz in the KRA
As promised, wiki documentation for this feature provided below: http://pki.fedoraproject.org/wiki/Kra_authz_realm Ade On Sat, 2016-04-16 at 17:24 -0400, Ade Lee wrote: > This is the main series of patches that implements fine grained > authorization in the KRA as described in : > > https://pagure.io/test_dogtag_designs/pull-request/5 > > I'll be moving this design to the wiki and adding some additional > documentation and test scripts shortly. > > More to come including : > 1. authz for the modify method in the Key service. > 2. new VLV indexes > 3. database migration script > 4. Man page updates > 5. Python unit tests for the Python CLI changes > > Please review, > > Thanks, > Ade > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [284] fix authority monitor so server can start up correctly
Acked by Endi through IRC. Pushed to master: To ssh://vakw...@git.fedorahosted.org/git/pki.git 88e963d..0c5fb1e master -> master On Fri, 2016-04-15 at 14:44 -0400, Ade Lee wrote: > Author: Ade Lee <a...@redhat.com> > Date: Fri Apr 15 14:36:00 2016 -0400 > > Add script to enable USN plugin > > New authority monitor code requires the USN plugin to be > enabled in the database to ensure that the entryUSN attribute > is added to authority entries. > > In the case where this plugin was disabled, accessing this > attribute resulted in a null pointer exception whch prevented > server > startup. > > The code has been changed so as not to throw a null pointer > exception > on startup if the entryusn is not present, and also to call an > LDIF > to enable the plugin when a subsystem is configured thorugh > pkispawn. > > Please review, > Ade > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication support
Couple of points on 96/97. 1. First off, I'm not sure you followed my concern about being able to distinguish between CA instances. On an IPA system, this is not an issue because there is only one CA on the server. In this case, I imagine there will be a well known directory which custodia would work with. In general though, we have to imagine that someone could end up installing two different dogtag ca instances on the same server. CMS.getEEHost() would result in the same value (the hostname) for both CAs. How does your helper program (or custodia) know which key to retrieve? The way to distinguish Dogtag instances is host AND port. 2. So, we're very careful that the signing keys are never in memory in the server. All accesses to the system certs are through JSS/NSS which essentially provides us handles to the keys. Now, I see a case where we import PKCS12 data AND the password into memory, so that we can import it into NSS? Say it ain't so .. With custodia, we have a secure mechanism of transferring the keys from one server to another. It makes more sense to me to have the server kick off the custodia transfer and then have that process also import into the NSS db. The server would then need to await status from the custodia/retriever process - and then initialize the signing unit from the NSS DB. Or am I completely confused? Ade On Thu, 2016-04-14 at 16:35 -0400, Ade Lee wrote: > Still reviewing .. ACK on 87-95 (inclusive). > > On Thu, 2016-04-14 at 16:18 +1000, Fraser Tweedale wrote: > > On Thu, Apr 14, 2016 at 09:04:31AM +1000, Fraser Tweedale wrote: > > > On Wed, Apr 13, 2016 at 05:26:44PM -0400, Ade Lee wrote: > > > > Still reviewing .. > > > > > > > > See comment on 87. ACK on 88,89,90,91,92,93, 94, 95. > > > > > > > > Ade > > > > > > > > On Mon, 2016-04-11 at 12:32 +1000, Fraser Tweedale wrote: > > > > > Thanks for review, Ade. Comments to specific feedback > > > > > inline. > > > > > Rebased and updated patches attached. The substantive > > > > > changes > > > > > are: > > > > > > > > > > - KeyRetriever implementations are now required NOT to import > > > > > the > > > > > key themselves. Instead the API is updated with > > > > > KeyRetriever.retrieveKey returning a Result, which contains > > > > > PKCS > > > > > #12 data and password for same. > > > > > > > > > > - KeyRetrieverRunner reads the Result and imports the PKCS > > > > > #12 > > > > > into > > > > > NSSDB. > > > > > > > > > > - Added new patch 0097 which provides the > > > > > IPACustodiaKeyRetriever > > > > > and assoicated Python helper script. It depends on an > > > > > unmerged > > > > > FreeIPA patch[1] as well as a particular principal and > > > > > associated > > > > > keytab and Custodia keys existing. I'm working on FreeIPA > > > > > updates > > > > > to satisfy these requirements automatically on install or > > > > > upgrade > > > > > but if you want to test this patch LMK and I'll provide > > > > > detailed > > > > > instructions. > > > > > > > > > > [1] > > > > > https://www.redhat.com/archives/freeipa-devel/2016-April/msg0 > > > > > 00 > > > > > 55.html > > > > > > > > > > Other comments inline. > > > > > > > > > > Cheers, > > > > > Fraser > > > > > > > > > > On Fri, Apr 08, 2016 at 11:16:19AM -0400, Ade Lee wrote: > > > > > > > > > > > > 0087 > > > > > > > > > > > > 1. In SigningUnit.java -- you catch an ObjectNotFound > > > > > > exception and > > > > > > rethrow that as a CAMissingKey exception. Is that the only > > > > > > way the > > > > > > ObjectNotFound exception can be thrown? What if the key is > > > > > > present > > > > > > but > > > > > > the cert is not? Can we refactor here to ensure that the > > > > > > correct > > > > > > exception is thrown? > > > > > > > > > > > One can't get additional info out of ObjectNotFound without > > > > > inspecting the String message, which I'm not comfortable > > > >
Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication support
96-2 looks like it does not apply. Please rebase . On Mon, 2016-04-11 at 12:32 +1000, Fraser Tweedale wrote: > Thanks for review, Ade. Comments to specific feedback inline. > Rebased and updated patches attached. The substantive changes are: > > - KeyRetriever implementations are now required NOT to import the > key themselves. Instead the API is updated with > KeyRetriever.retrieveKey returning a Result, which contains PKCS > #12 data and password for same. > > - KeyRetrieverRunner reads the Result and imports the PKCS #12 into > NSSDB. > > - Added new patch 0097 which provides the IPACustodiaKeyRetriever > and assoicated Python helper script. It depends on an unmerged > FreeIPA patch[1] as well as a particular principal and associated > keytab and Custodia keys existing. I'm working on FreeIPA updates > to satisfy these requirements automatically on install or upgrade > but if you want to test this patch LMK and I'll provide detailed > instructions. > > [1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg000 > 55.html > > Other comments inline. > > Cheers, > Fraser > > On Fri, Apr 08, 2016 at 11:16:19AM -0400, Ade Lee wrote: > > > > 0087 > > > > 1. In SigningUnit.java -- you catch an ObjectNotFound exception and > > rethrow that as a CAMissingKey exception. Is that the only way the > > ObjectNotFound exception can be thrown? What if the key is present > > but > > the cert is not? Can we refactor here to ensure that the correct > > exception is thrown? > > > One can't get additional info out of ObjectNotFound without > inspecting the String message, which I'm not comfortable doing. The > key retrieval system should import key and cert at same time so I've > renamed the exception to CAMissingKeyOrCert for clarity. > > > 0088: > > > > 2. What does dbFactory.reset() do and does it need to be called in > > a > > cleanup routine somewhere? Are we leaking resources? > > > > Answered I think on IRC. It just terminates any current > > connections - > > but do we need to call it on CA shutdown? > > > dbFactory.reset() is already called in the shutdown() method. (Only > the host authority calls it). > > > 0089: ACK > > > > 0090: ACK > > > > 0091: ACK (with proviso below) > > > > 3. Not super-crazy about the names of the methods > > commitAuthority(), > > commitModifyAuthority and deleteAuthorityEntry(). They are not > > very > > consistent. I would suggest addAuthorityEntry(), > > modifyAuthorityEntry() and deleteAuthorityEntry() instead. > > > Done. > > > 0092: ACK (with following proviso) > > > > 4. Talking with Nathan about this, he suggested that syncrepl is > > then > > more modern and preferred method to perform persistent searches. > > In > > fact, I see IPA tickets to replace persistent searches with > > syncrepl > > instead. > > > > We could replace the persistent search with a separate follow-on > > patch > > if you prefer, or just do it now. > > > Syncrepl is not supported by ldapjdk (iirc). If/when it is, and if > syncrepl provides a tangible advantage over persistent search in our > use case (where it can be assumed that disconnections from DS are > infrequent and brief, and full refresh of local view is tolerable), > then I am happy to change it - in a separate commit (because > LDAPProfileSubsystem is also affected). > > > 0093 : ACK > > > > 0094: ACK > > > > 0095: ACK > > > > 0096: Looks good in general. > > > > 5. One thing to keep in mind though. It is perfectly possible to > > have > > more than one dogtag instance on a host. What determines the > > uniqueness of the instance is the host:port. > > > Noted. KeyRetriever implementations can access instance info via > the `CMS' class. > > Cheers, > Fraser ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication support
Still reviewing ..
See comment on 87. ACK on 88,89,90,91,92,93, 94, 95.
Ade
On Mon, 2016-04-11 at 12:32 +1000, Fraser Tweedale wrote:
> Thanks for review, Ade. Comments to specific feedback inline.
> Rebased and updated patches attached. The substantive changes are:
>
> - KeyRetriever implementations are now required NOT to import the
> key themselves. Instead the API is updated with
> KeyRetriever.retrieveKey returning a Result, which contains PKCS
> #12 data and password for same.
>
> - KeyRetrieverRunner reads the Result and imports the PKCS #12 into
> NSSDB.
>
> - Added new patch 0097 which provides the IPACustodiaKeyRetriever
> and assoicated Python helper script. It depends on an unmerged
> FreeIPA patch[1] as well as a particular principal and associated
> keytab and Custodia keys existing. I'm working on FreeIPA updates
> to satisfy these requirements automatically on install or upgrade
> but if you want to test this patch LMK and I'll provide detailed
> instructions.
>
> [1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg000
> 55.html
>
> Other comments inline.
>
> Cheers,
> Fraser
>
> On Fri, Apr 08, 2016 at 11:16:19AM -0400, Ade Lee wrote:
> >
> > 0087
> >
> > 1. In SigningUnit.java -- you catch an ObjectNotFound exception and
> > rethrow that as a CAMissingKey exception. Is that the only way the
> > ObjectNotFound exception can be thrown? What if the key is present
> > but
> > the cert is not? Can we refactor here to ensure that the correct
> > exception is thrown?
> >
> One can't get additional info out of ObjectNotFound without
> inspecting the String message, which I'm not comfortable doing. The
> key retrieval system should import key and cert at same time so I've
> renamed the exception to CAMissingKeyOrCert for clarity.
>
Well, you can always nest exceptions like so :
mToken.login(cb); // ONE_TIME by default.
try {
mCert = mManager.findCertByNickname(mNickname);
CMS.debug("Found cert by nickname: '" + mNickname + "' with
serial number: " + mCert.getSerialNumber());
mCertImpl = new X509CertImpl(mCert.getEncoded());
CMS.debug("converted to x509CertImpl");
} catch (ObjectNotFoundException e) {
throw new CAMissingCertException();
}
try {
mPrivk = mManager.findPrivKeyByCert(mCert);
CMS.debug("Got private key from cert");
} catch (ObjectNotFoundException e) {
throw new CAMissingKeyException();
}
The only reason that I suggest this is that I could imagine this kind
of differentiation being useful in debugging failed custodia
replications. If you think otherwise, I'm prepare to be convinced
otherwise.
> > 0088:
> >
> > 2. What does dbFactory.reset() do and does it need to be called in
> > a
> > cleanup routine somewhere? Are we leaking resources?
> >
> > Answered I think on IRC. It just terminates any current
> > connections -
> > but do we need to call it on CA shutdown?
> >
> dbFactory.reset() is already called in the shutdown() method. (Only
> the host authority calls it).
>
> > 0089: ACK
> >
> > 0090: ACK
> >
> > 0091: ACK (with proviso below)
> >
> > 3. Not super-crazy about the names of the methods
> > commitAuthority(),
> > commitModifyAuthority and deleteAuthorityEntry(). They are not
> > very
> > consistent. I would suggest addAuthorityEntry(),
> > modifyAuthorityEntry() and deleteAuthorityEntry() instead.
> >
> Done.
>
> > 0092: ACK (with following proviso)
> >
> > 4. Talking with Nathan about this, he suggested that syncrepl is
> > then
> > more modern and preferred method to perform persistent searches.
> > In
> > fact, I see IPA tickets to replace persistent searches with
> > syncrepl
> > instead.
> >
> > We could replace the persistent search with a separate follow-on
> > patch
> > if you prefer, or just do it now.
> >
> Syncrepl is not supported by ldapjdk (iirc). If/when it is, and if
> syncrepl provides a tangible advantage over persistent search in our
> use case (where it can be assumed that disconnections from DS are
> infrequent and brief, and full refresh of local view is tolerable),
> then I am happy to change it - in a separate commit (because
> LDAPProfileSubsystem is also affected).
>
> > 0093 : ACK
> >
> > 0094: ACK
> >
> > 0095: ACK
> >
> > 0096: Looks good in general.
> >
> > 5. One thing to keep in mind though. It is perfectly possible to
> > have
> > more than one dogtag instance on a host. What determines the
> > uniqueness of the instance is the host:port.
> >
> Noted. KeyRetriever implementations can access instance info via
> the `CMS' class.
>
> Cheers,
> Fraser
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication support
A few comments.
1. One of the first things that struck me as odd was making
CertificateAuthority implement Runnable. I think it would be cleaner
to have a static inner class called AuthorityMonitor or similar to
which we pass in the CertificateAuthority.
2. I do like the fact that the caMap updates are done through a static
database connection factory created by the hostCA. How do you ensure
that the database connection factory is created before being used by
other CAs?
3. I'm not sure I understand how the initialLoadDone counter is
supposed to work. Are all the CA's supposed to stop until the hostCA
has completed its initial load? Because it looks like only the hostCA
calls await().
4. There is a lot of code in that initial patch. It would help review
to split that off into at least two patches, say one in which you add
the functions in CertificateAuthority that handle modifications in the
caMap based on persistent search results, and one which adds the new
monitor thread.
5. Some in-code documentation would not go amiss. For instance, I have
no idea why this code is correct --
String[] objectClasses =
entry.getAttribute("objectClass").getStringValueArray();
if
(Arrays.asList(objectClasses).contains("organizationalUnit")) {
initialNumAuthorities = new Integer(
entry.getAttribute("numSubordinates")
.getStringValueArray()[0]);
checkInitialLoadDone();
continue;
}
organizationalUnit?
There are lots of different variables like initialNumAuthorities etc. which
could
potentially be hidden in an inner class, making this more understandable.
Ade
On Tue, 2016-03-22 at 16:00 +1000, Fraser Tweedale wrote:
> On Fri, Mar 18, 2016 at 02:30:24PM +1000, Fraser Tweedale wrote:
> > Hi all,
> >
> > The attached patches implement replication support for lightweight
> > CAs. These patches do not implement key replication via Custodia
> > (my next task) but they do implement the persistent search thread
> > and appropriate** API behaviour when the signing keys are not yet
> > available.
> >
> > ** In most cases, we respond 503 Service Unavailable; this is open
> >for discussion. ca-authority-find and ca-authority-show include
> >a boolean field indicating whether the CA is ready to sign.
> >There might be (probably are) endpoints I've missed.
> >
> > Cheers,
> > Fraser
> >
> Updated patches attached - small change in patch 0084 to fix a race
> condition when deleting an authority that can cause NPE.
>
> Thanks,
> Fraser
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 699 Fixed exception handling in EnrollProfile.
ACK On Mon, 2016-03-21 at 11:55 -0500, Endi Sukma Dewata wrote: > To help troubleshooting the EnrollProfile has been modified to > log the stack trace and chain the exception. > > https://fedorahosted.org/pki/ticket/1654 > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 698 Added support for cloning 3rd-party CA certificates.
ack On Fri, 2016-03-18 at 11:31 -0500, Endi Sukma Dewata wrote: > The installation code has been modified such that it imports all > CA certificates from the PKCS #12 file for cloning before the > server is started using certutil. The user certificates will > continue to be imported using the existing JSS code after the > server is started. This is necessary since JSS is unable to > preserve the CA certificate nicknames. > > The PKCS12Util has been modified to support multiple certificates > with the same nicknames. > > The pki pkcs12-cert-find has been modified to show certificate ID > and another field indicating whether the certificate has a key. > > The pki pkcs12-cert-export has been modified to accept either > certificate nickname or ID. > > The pki pkcs12-import has been modified to provide options for > importing only user certificates or CA certificates. > > https://fedorahosted.org/pki/ticket/1742 > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0057-0059 RHEL fixes and preparations for Python 3
ACK On Wed, 2016-03-02 at 19:47 +0100, Christian Heimes wrote: > Hi, > > here a three patch that I like to push upstream before I finalize my > Python 3 branch. > > The first patch addresses an incompatibility with python-sphinx 1.1 > that > I introduced last week. The chance is required to build Dogtag on > RHEL 7. > > The second patch just moves some Python dependencies from pki-base to > pki-server. > > The last one fixes another issue with RHEL and simplifies the spec > file. > > Christian > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 281 - separate pki-base into python and java components
Thanks. Fixed. pushed to master.
To ssh://vakw...@git.fedorahosted.org/git/pki.git
11f8fbb..49e4fff master -> master
On Tue, 2016-03-01 at 12:44 +0100, Christian Heimes wrote:
> On 2016-03-01 06:53, Ade Lee wrote:
> > In this patch, I move all java components (and requirements) for
> > pki-base to a new package pki-base-java.
> >
> > This makes the footprint much smaller for dogtag python clients -
> > like openstack for instance.
>
> Shouldn't pki-base-java depend on pki-base, too?
>
> %package -n pki-base-java
> ...
> Requires: pki-base = %{version}-%{release}
>
> Christian
>
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [PATCH] 278 - handle external certs
This is to resolve ticket 1742. For this ticket, we need a mechanism to import third party certs to clones. This patch provides a general mechanism to do this. A follow-on patch with documentation on how this all works is forthcoming. AdeFrom ae19db5c895e1c70e98de0ff7b825c8801c98e1f Mon Sep 17 00:00:00 2001 From: Ade Lee <a...@redhat.com> Date: Sat, 27 Feb 2016 02:32:14 -0500 Subject: [PATCH] Handle import and export of external certs Ticket 1742 has a case where a third party CA certificate has been added by IPA to the dogtag certdb for the proxy cert. There is no way to ensure that this certificate is imported when the system is cloned. This patch will allow the user to import third party certificates into a dogtag instance through CLI commands (pki-server). The certs are tracked by a new instance level configuration file external_certs.conf. Then, when cloning: 1. When the pk12 file is created by the pki-server ca-clone-prepare command, the external certs are automatically included. 2. When creating the clone, the new pki_server_pk12_path and password must be provided. Also, a copy of the external_certs.conf file must be provided. 3. This copy will be read and merged with the existing external_certs.conf if one exists. --- base/common/python/pki/nssdb.py| 27 +-- base/server/python/pki/server/__init__.py | 106 base/server/python/pki/server/cli/ca.py| 10 +- base/server/python/pki/server/cli/instance.py | 185 + base/server/python/pki/server/cli/kra.py | 10 +- base/server/python/pki/server/cli/ocsp.py | 7 +- base/server/python/pki/server/cli/tks.py | 7 +- base/server/python/pki/server/cli/tps.py | 7 +- .../server/deployment/scriptlets/configuration.py | 2 +- .../deployment/scriptlets/security_databases.py| 36 +++- 10 files changed, 373 insertions(+), 24 deletions(-) diff --git a/base/common/python/pki/nssdb.py b/base/common/python/pki/nssdb.py index b2cf9f1cf0ceaa06a5b1df193bd9aef9da0525f7..8d0f96711be3012ec4618dfb51b1d463f675d673 100644 --- a/base/common/python/pki/nssdb.py +++ b/base/common/python/pki/nssdb.py @@ -377,7 +377,8 @@ class NSSDatabase(object): subprocess.check_call(cmd) -def import_cert_chain(self, nickname, cert_chain_file, trust_attributes=None): +def import_cert_chain(self, nickname, cert_chain_file, + trust_attributes=None): tmpdir = tempfile.mkdtemp() @@ -389,16 +390,18 @@ class NSSDatabase(object): nickname=nickname, cert_file=cert_chain_file, trust_attributes=trust_attributes) -return self.get_cert( -nickname=nickname, -output_format='base64') +return ( +self.get_cert(nickname=nickname, output_format='base64'), +[nickname] +) elif file_type == 'pkcs7': # import PKCS #7 cert chain -return self.import_pkcs7( +chain, nicks = self.import_pkcs7( pkcs7_file=cert_chain_file, nickname=nickname, trust_attributes=trust_attributes, output_format='base64') +return chain, nicks else: # import PKCS #7 data without header/footer with open(cert_chain_file, 'r') as f: @@ -409,17 +412,18 @@ class NSSDatabase(object): with open(tmp_cert_chain_file, 'w') as f: f.write(pkcs7_data) -self.import_pkcs7( +chain, nicks = self.import_pkcs7( pkcs7_file=tmp_cert_chain_file, nickname=nickname, trust_attributes=trust_attributes) -return base64_data +return base64_data, nicks finally: shutil.rmtree(tmpdir) -def import_pkcs7(self, pkcs7_file, nickname, trust_attributes=None, output_format='pem'): +def import_pkcs7(self, pkcs7_file, nickname, trust_attributes=None, + output_format='pem'): tmpdir = tempfile.mkdtemp() @@ -435,6 +439,7 @@ class NSSDatabase(object): # parse PEM output into separate PEM certificates certs = [] lines = [] +nicks = [] state = 'header' for line in output.splitlines(): @@ -476,6 +481,7 @@ class NSSDatabase(object): n = '%s #%d' % (nickname, counter) self.add_cert(n, cert_file, trust_attributes) +nicks.append(n) counter += 1 @@ -483,12 +489,13 @@ class NSSDatabase(object): with open(pkcs7_file, 'r') as f: data = f.read() -return convert_pkcs7(data, 'pem', output_
Re: [Pki-devel] [PATCH] 277 - add precheck option to pkispawn
acked by Endi. Pushed to master. On Tue, 2016-02-23 at 14:43 -0500, Ade Lee wrote: > Add precheck option to pkispawn. This runs various tests > without actually doing any installation to ensure that the > pkipawn parameters are sane. > > https://fedorahosted.org/pki/ticket/2042 > > Please review, > > Thanks, > Ade > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 0050 Lightweight CAs: ensure disabled CA cannot create sub-CA
ACK - Looks like our integration framework isn't there yet, and no reason to hold this up till it is. On Fri, 2015-10-02 at 14:35 -0400, Ade Lee wrote: > Conditional ACK. > > The patch itself is fine. However, its time we got into the habit of > adding functional tests for fixes we make. > > We don't really have a good place for these, but there is a > placeholder > location in the main_ function in the authority.py python file. We > need to add some test code there. We'll need to revamp these tests > soon and use the pytest framework, but we won't know to test this > condition unless the test case is there. > > So, please add soem test code and confirm it works. > > Ade > > ps. You'll probably want to check in your delete patch and the > correspo > nding python code first. > > > On Thu, 2015-10-01 at 13:53 +1000, Fraser Tweedale wrote: > > The attached patch (which replaces an earlier patch 0050) fixes > > https://fedorahosted.org/pki/ticket/1628. > > > > Cheers, > > Fraser > > ___ > > Pki-devel mailing list > > Pki-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > ___ > Pki-devel mailing list > Pki-devel@redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [PATCH] 275 - remove dnsdomainname check
Thanks for the check Endi. Lets try this again. This time, we default instead to the hostname, instead of exiting. Ade On Tue, 2016-02-09 at 11:38 -0600, Endi Sukma Dewata wrote: > On 2/9/2016 10:53 AM, Ade Lee wrote: > > This check is unnecessary and is breaking continuous integration in > > OpenStack. Removing from pkispawn/pkidestroy. > > > > Ade > > If I'm reading the code correctly the pki_dns_domainname is used as a > label to populate other properties (e.g. security domain names, admin > email, nickname). While the label itself is not crucial to server > operations, the patch removes the code that's supposed obtain the > proper > label. So under normal usage (i.e. outside CI) the pki_dns_domainname > will be None, and those other properties will have incomplete values. > > I think there are several options: > > 1. Instead of removing the check, the code should assign a better > default value (e.g. example.com) to pki_dns_domainname if the domain > name is not available due to CI. > > 2. Remove the check, but also remove all references to > pki_dns_domainname from the entire code. > From e410eed7eace50a9ebb7057c574934445e3b1ee0 Mon Sep 17 00:00:00 2001 From: Ade Lee <a...@redhat.com> Date: Wed, 10 Feb 2016 07:01:14 -0500 Subject: [PATCH] Modify dnsdomainname test in pkispawn We do a check for the dnsdomainname, which fails in Openstack CI because this is not set. Instead of exiting, default to the hostname. --- base/server/python/pki/server/deployment/pkimessages.py | 2 +- base/server/sbin/pkidestroy | 2 +- base/server/sbin/pkispawn | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/base/server/python/pki/server/deployment/pkimessages.py b/base/server/python/pki/server/deployment/pkimessages.py index b16051b6c19f1e6d8d88b7419781a11c5dee27f4..b58915fe269c26bece62677974431caf783004c4 100644 --- a/base/server/python/pki/server/deployment/pkimessages.py +++ b/base/server/python/pki/server/deployment/pkimessages.py @@ -69,7 +69,7 @@ PKI_DIRECTORY_ALREADY_EXISTS_NOT_A_DIRECTORY_1 = \ PKI_DIRECTORY_MISSING_OR_NOT_A_DIRECTORY_1 = \ "Directory '%s' is either missing or is NOT a directory!" PKI_DNS_DOMAIN_NOT_SET = \ -"A valid DNS domain name MUST be established to use PKI services!" +"DNS domain name has not been set - using the hostname instead." PKI_FILE_ALREADY_EXISTS_1 = "File '%s' already exists!" PKI_FILE_ALREADY_EXISTS_NOT_A_FILE_1 = \ "File '%s' already exists BUT it is NOT a file!" diff --git a/base/server/sbin/pkidestroy b/base/server/sbin/pkidestroy index 032c97984280a8c6ef701acfdeced6a066f56801..12d37f2f39b56958e95eea98d92128d8f206301c 100755 --- a/base/server/sbin/pkidestroy +++ b/base/server/sbin/pkidestroy @@ -91,7 +91,7 @@ def main(argv): config.pki_dns_domainname = dnsdomainname if not len(config.pki_dns_domainname): print(log.PKI_DNS_DOMAIN_NOT_SET) -sys.exit(1) +config.pki_dns_domainname = config.pki_hostname except subprocess.CalledProcessError as exc: print(log.PKI_SUBPROCESS_ERROR_1 % exc) sys.exit(1) diff --git a/base/server/sbin/pkispawn b/base/server/sbin/pkispawn index 7d839851faa20ebd5b53b0dd3be2fc77e0a3f69f..5892a671f3bf286553efeed3e63fd96b7a0265bd 100755 --- a/base/server/sbin/pkispawn +++ b/base/server/sbin/pkispawn @@ -93,7 +93,7 @@ def main(argv): config.pki_dns_domainname = dnsdomainname if not len(config.pki_dns_domainname): print(log.PKI_DNS_DOMAIN_NOT_SET) -sys.exit(1) +config.pki_dns_domainname = config.pki_hostname except subprocess.CalledProcessError as exc: print(log.PKI_SUBPROCESS_ERROR_1 % exc) sys.exit(1) -- 2.4.3 ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
