This issue was migrated from Pagure Issue #30. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:30:55:

• Closed as None
• Assigned to vakwetu (@vakwetu)

#No Description Provided

This issue was migrated from Pagure Issue #31. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:31:57:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

#No Description Provided

This issue was migrated from Pagure Issue #25. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:06:38:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

GET /pki/keyrequests
GET /pki/keyrequests/$id

• get all types of keys/requests. We care about archival and recovery first

This issue was migrated from Pagure Issue #24. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:01:35:

• Assigned to vakwetu (@vakwetu)

POST /pki/keyrequest/archive

• unpack parameters
• create an archival request (with relevant parameters in right place)
• get kra request queue
• add new request to queue
• return id of archival request

This issue was migrated from Pagure Issue #34. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:48:12:

• Assigned to vakwetu (@vakwetu)

Is this a task for some IPA resource/ community member?

dummy proxy

• proxies back requests for pin
• agent logs into ipa and approves, and provides pin out of band
• proxies back requests for SCEP

This issue was migrated from Pagure Issue #11. Originally filed by jmagne (@jmagne) on 2011-11-15 02:57:27:

• Closed as Fixed
• Assigned to jmagne (@jmagne)

We need to come up with a set of requirements for extracting the Auth and Authz code from CS and into the Container based model supported in Tomcat through the use of Realms. The following is a rough list of some of the issues to be resolved:

1. Are we going to support cert auth and kerberos?

2. Is the so called Combined Realm approach going to work? From my research you can supply a list of sub Realms and the auth is attempted one at a time and when one succeeds, the user is authenticated.

3. For CS we kind of have two levels of authentication. 1) At the Connector level or socket level using "tomcatjss", which can be used to request SSL client auth. 2) Once the user passes that, the server itself has various authentication managers for specific certificate enrollment profiles based on what you are trying to do. For instance there are ldap based authentication, flat file based authentication, and certificate based authentication methods based on the certificate profile in use. Also, the server sometimes will ask for a certificate on the fly if required after initial negotiation. This kind of flexibility would be hard to simply rip out of the server and put into Realms. Will the Realms serve as an additional level of security to this or will it somehow replace it all? I would assume the goal would be to bring it all outside so it can be reused by others.

4. The server also supports and extensive AuthZ framework based on role users such as EE users and Agent, and Admin users. Each attempt to do something is checked against the mapped role user and a series of ACLs. Would all of this have to somehow be extracted out into the Realms? Looking at the JAAS Realm stuff, the notion of User and Role classes are part of the mix.

5. In looking at the Combined Realm approach, it appears to merely support the notion of falling back to the next method if the current method fails. In CS, we often dynamically choose the authentication method, how would this work? It looks like the Realm is only configurable one per Tomcat "Engine". This means all the supplies Connectors would be held to this on Realm or Combined Realm. Can we work with this?

6. Do we need some sort of JSS/NSS JAAS realm to support client auth? If so what would it do? What would become of the tomcatjss controlled listening sockets?

This issue was migrated from Pagure Issue #41. Originally filed by admiyo on 2011-11-17 17:12:58:

• Assigned to nobody

The Class CMS Engine acts as a dependency Knot. Many classes call upon ICMSEngine merely to get their dependencies fulfilled. A better approach is to use something like Pico, Nano, or Spring to perform inversion of control.

This issue was migrated from Pagure Issue #8. Originally filed by admiyo on 2011-11-11 22:10:31:

• Closed as Duplicate
• Assigned to admiyo

import org.mozilla.jss.crypto.Signature; needs to be replaced with java.security.Signature and all code that usese the old call needs to use the new.

This issue was migrated from Pagure Issue #9. Originally filed by admiyo on 2011-11-11 22:44:56:

• Closed as Fixed
• Assigned to mharmsen (@mharmsen)

This used to be /usr/lib/java but is now /usr/lib64/java when building 64 bit on 64. For 32 on 32 or 32 on 64 the value should remain /usr/lib/java

This issue was migrated from Pagure Issue #17. Originally filed by mharmsen (@mharmsen) on 2011-11-15 03:46:22:

• Closed at 2017-04-07 16:58:32 as fixed
• Assigned to cfu (@cfu)

The JSS component is used to provide cryptographic access from all Java-based subsystems of Dogtag to NSS.

Fedora and Red Hat operating systems utilize JSS 4.2.6 which exists solely as an SRPM with numerous patches.

The upstream source code for version 4.2.6 of JSS exists on a branch located at the Mozilla Foundation (version 4.3 is the TIP).

After I have obtained check-in privileges and have become the maintainer of JSS, I need to accomplish the following:

- integrate all existing JSS 4.2.6 patches into the JSS 4.3 source code
- create JSS 4.3 packages for all Fedora and Red Hat platforms
- migrate PKI packages to utilize JSS 4.3 (rather than JSS 4.2.6)

This issue was migrated from Pagure Issue #4. Originally filed by vakwetu (@vakwetu) on 2011-11-11 20:02:48:

• Closed as Invalid
• Assigned to vakwetu (@vakwetu)

Write IPA python code to add schema, users, initial database suffixes for CA and DRM. And call pkicreate using IPA-specific pkicreate config file. Do the same for cloned configurations.

This issue was migrated from Pagure Issue #3. Originally filed by admiyo on 2011-11-11 19:55:50:

• Closed as Fixed
• Assigned to edewata (@edewata)

Eclipse generates 1505 Warnings for places where deprecated Code is used. These need to be replaced with the appropriate modernized API calls.

This issue was migrated from Pagure Issue #16. Originally filed by mharmsen (@mharmsen) on 2011-11-15 03:42:27:

• Closed as Fixed
• Assigned to mharmsen (@mharmsen)

The JSS component is used to provide cryptographic access from all Java-based subsystems of Dogtag to NSS.

Fedora and Red Hat operating systems utilize JSS 4.2.6 which exists solely as an SRPM with numerous patches.

The upstream source code for version 4.2.6 of JSS exists on a branch located at the Mozilla Foundation (version 4.3 is the TIP), and as there are no current maintainers of the JSS project, I need to work with the Mozilla Foundation to become the maintainer of this package, and obtain check-in access to this project.

This issue was migrated from Pagure Issue #13. Originally filed by jmagne (@jmagne) on 2011-11-15 03:14:37:

• Closed as Fixed
• Assigned to jmagne (@jmagne)

Based on results of requirements gathering, come up with a design on how to actually accomplish the required functionality.

Make unit-test is failed, error log is below:
make_unit-test.log

Tests error logs are attached:
TEST-com.netscape.cmscore.authentication.AuthTokenTest.xml.txt
TEST-com.netscape.cmscore.request.RequestTest.xml.txt

Using jdb, i see:

main[1] list
330            X509CertImpl cert = getFakeCert();
331
332            assertFalse(cmsStub.bToACalled);
333            assertTrue(request.setExtData("key", cert));
334 =>         assertTrue(cmsStub.bToACalled);
335
336            assertFalse(cmsStub.aToBCalled);
337            X509CertImpl retval = request.getExtDataInCert("key");
338            assertTrue(cmsStub.aToBCalled);
339            assertEquals(cert, retval);

main[1] dump cmsStub.bToACalled
 cmsStub.bToACalled = false
main[1] dump cmsStub
 cmsStub = {
    bToACalled: false
    bToACalledWith: null
    aToBCalled: false
    aToBCalledWith: null
}

main[1] where
  [1] com.netscape.cmscore.request.RequestTest.testGetSetCert (RequestTest.java:334)
  [2] sun.reflect.NativeMethodAccessorImpl.invoke0 (native method)
  [3] sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
  [4] sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
  [5] java.lang.reflect.Method.invoke (Method.java:498)
  [6] junit.framework.TestCase.runTest (TestCase.java:176)
  [7] junit.framework.TestCase.runBare (TestCase.java:141)
  [8] junit.framework.TestResult$1.protect (TestResult.java:122)
  [9] junit.framework.TestResult.runProtected (TestResult.java:142)
  [10] junit.framework.TestResult.run (TestResult.java:125)
  [11] junit.framework.TestCase.run (TestCase.java:129)
  [12] junit.framework.TestSuite.runTest (TestSuite.java:252)
  [13] junit.framework.TestSuite.run (TestSuite.java:247)
  [14] org.junit.internal.runners.JUnit38ClassRunner.run (JUnit38ClassRunner.java:86)
  [15] org.junit.runners.Suite.runChild (Suite.java:128)
  [16] org.junit.runners.Suite.runChild (Suite.java:27)
  [17] org.junit.runners.ParentRunner$3.run (ParentRunner.java:290)
  [18] org.junit.runners.ParentRunner$1.schedule (ParentRunner.java:71)
  [19] org.junit.runners.ParentRunner.runChildren (ParentRunner.java:288)
  [20] org.junit.runners.ParentRunner.access$000 (ParentRunner.java:58)
  [21] org.junit.runners.ParentRunner$2.evaluate (ParentRunner.java:268)
  [22] org.junit.runners.ParentRunner.run (ParentRunner.java:363)
  [23] org.junit.runner.JUnitCore.run (JUnitCore.java:137)
  [24] org.junit.runner.JUnitCore.run (JUnitCore.java:115)
  [25] org.junit.runner.JUnitCore.run (JUnitCore.java:105)
  [26] org.junit.runner.JUnitCore.run (JUnitCore.java:94)
  [27] com.netscape.test.TestRunner.run (TestRunner.java:29)
  [28] com.netscape.test.TestRunner.main (TestRunner.java:39)
main[1]

So, there are no CMS.AtoB/BtoA calls(perhaps after 94837a1e00822c7494a2acb73dc18dbc337bc314 and 0beebcfc589e73872a837ac04b2560f04ec795c2) and CMSMemoryStub class looks like outdated

    /** 
     * CMSMemoryStub
     *
     * This class is used to help test methods that rely on setting and then
     * getting a value out. It assumes BtoA is always called first, stores
     * the value passed in, and then returns that value for BtoA.
     */
    static class CMSMemoryStub extends CMSEngineDefaultStub {
        boolean bToACalled = false;
        byte[] bToACalledWith = null;

        boolean aToBCalled = false;
        String aToBCalledWith = null;

        public String BtoA(byte data[]) {
            bToACalled = true;
            bToACalledWith = data;
            return "garbagetostoreinthehash";
        }

        public byte[] AtoB(String data) {
            aToBCalled = true;
            aToBCalledWith = data;
            return bToACalledWith;
        }
    }

This issue was migrated from Pagure Issue #32. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:36:06:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

• Determine servlets to be exposed in proxy.conf
• Determine config changes (if any) on dogtag-ra

Changes required documented at:
http://pki.fedoraproject.org/wiki/SCEP_in_IPA

This issue was migrated from Pagure Issue #36. Originally filed by edewata (@edewata) on 2011-11-15 20:30:30:

• Closed as Fixed
• Assigned to edewata (@edewata)

The CMake build system needs to be able to build and execute JUnit tests, parse the results of individual tests, terminate the build process if there's a failure, and generate a report that can be posted into a CI tool such as Hudson.

This issue was migrated from Pagure Issue #35. Originally filed by vakwetu (@vakwetu) on 2011-11-15 07:20:59:

• Closed as Invalid
• Assigned to nkinder (@nkinder)

Coverity reports the following:

• 89 resource leaks -- mostly not closing data streams in finally blocks etc. These should all be handled consistently
• 10 class hierarchy violation
• 42 concurrency violation
• 1 control flow (unreachable code)
• 2 incorrect expression
• 1 integer handling
• 266 null pointer derefs
• 123 findbugs: bad practice
• 599 findbugs : dodgy
• 238 findbugs: performance
• 21 findbugs: correctness
• 14 findbugs: multithreaded correctness

We need to figure out how to create bugs/tasks accordingly

This issue was migrated from Pagure Issue #15. Originally filed by mharmsen (@mharmsen) on 2011-11-15 03:20:23:

• Closed as Fixed
• Assigned to mharmsen (@mharmsen)

The current 'pkicreate' and 'pkiremove' instance scripts are currently written in Perl, and the 'pkisilent' instance configuration tool is written in Java. Although these scripts/tools contain numerous command-line parameters which make them highly configurable, this approach does not necessarily make them suitable for simple integration into other products.

To simplify the use of embedding these tools, there is a desire to re-design, re-factor, and simplify these tools to make them easier for general use by other products.

Some preliminary ideas include the following:

- combining the pkicreate and pkisilent tools into a single utility
- use of a configuration file with default values for ease of use
- use of Python as the language to replace Perl/Java
- first-pass will be to support simple default cases only; for later phases of this
  re-design, allow command-line parameters to override values contained in the
  configuration file

It seems on the 10.3.X branch of code the endpoint /ca/rest/certrequests/{id} will return a 500 error. On the 10.2.x branch, tested on Fedora 23, this call would return the correct response of the cert request with the corresponding id. The error on 10.3.x was observed on Fedora 24,25, and 26 by following the process outlined on http://pki.fedoraproject.org/wiki/Quick_Start.

Is there something missing in the documentation that is needed to make the api call functional like a specific version of a java library and/or tomcat that isn't specified in the dogtag-pki deb?

Link to the http error and the tomcat error output:
https://gist.github.com/illegalhex/3e5497d18518e58a9c1ecdd49acd0d74

This issue was migrated from Pagure Issue #22. Originally filed by vakwetu (@vakwetu) on 2011-11-15 05:55:48:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

POST /pki/keyrequest/archive

• unpack parameters
• create an archival request (with relevant parameters in right place)
• get kra request queue
• add new request to queue
• return id of archival request

This issue was migrated from Pagure Issue #18. Originally filed by jmagne (@jmagne) on 2011-11-15 03:53:51:

• Closed as Invalid
• Assigned to jmagne (@jmagne)

Based on design and requirements decisions it may turn out that we need to implement our own JSS based Realm. If we want to package up JSS based authentication technology (ex certificate auth), this may be the way to do it.

This issue was migrated from Pagure Issue #20. Originally filed by vakwetu (@vakwetu) on 2011-11-15 05:44:17:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

RESTeasy is supported by RH/JBoss. We can get help from candlepin group.
-- Can we get a maintainer for incorporating it into Fedora?
-- RESTeasy is already in RHEL?

Jersey is reference JAX-RS implementation, appears to be easier.
-- may be harder to find a maintainer.

Run flake test with command:
flake8 --config tox.ini ~/tmp/pki-core-buildroot

Error log:

/usr/src/tmp/pki-core-buildroot/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py:620:9: E722 do not use bare except' 
        except:
        ^
/usr/src/tmp/pki-core-buildroot/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py:639:9: E722 do not use bare except' 
        except:
        ^
flake8.main.application   MainProcess   2724 INFO     Found a total of 2 violations and reported 2

Flake version:

flake8 --version
3.5.0 (mccabe: 0.6.1, pycodestyle: 2.3.1, pyflakes: 1.6.0) CPython 2.7.14 on Linux

PKI version:
v10.5.3

This issue was migrated from Pagure Issue #27. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:22:42:

• Assigned to vakwetu (@vakwetu)

POST /pki/keyrequest/recovery
PUT /pki/keyrequest/$rid/status (status= approved - updates the quorum)
GET /pki/keyrequest/$rid/status

GET /pki/key/$kid - including wrapping mechanisms

This issue was migrated from Pagure Issue #45. Originally filed by vakwetu (@vakwetu) on 2011-11-23 17:52:29:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

Once standards decided:

1. Create relevant eclipse project settings and commit
2. Do automatic reformatting on the trunk.

This issue was migrated from Pagure Issue #2. Originally filed by admiyo on 2011-11-11 19:50:20:

• Closed as Fixed
• Assigned to edewata (@edewata)

There are 5353 warnings generated in that come from the upgrade of the JDK to a version that supports Generics. These calls should be converted to use the appropriate, most specific Data datatypes.

This issue was migrated from Pagure Issue #39. Originally filed by vakwetu (@vakwetu) on 2011-11-16 00:35:30:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

#No Description Provided

This issue was migrated from Pagure Issue #40. Originally filed by admiyo on 2011-11-16 21:34:59:

• Assigned to edewata (@edewata)

Certificates make use of the interface CertAttrSet. This has a couple methods that assume Hashtable type behavior:

void set(String name, Object obj)
    throws CertificateException, IOException;

Object get(String name)
throws CertificateException, IOException;

One class that implements this interface is netscape.security.x509.Extensions which also extends Hashtable.
At some place, code pulls objects out of the Hashtables and assumes that they can be case to netscape.security.x509.Extension but other places stoer primiteive wrappers in the Hashtable and so forth.

This interface needs to be split into more appropriate pieces. THere should be one interface for managing collections of Extension, and a different one for handling getting/seeting the primitives and other attribute of certificates.

This issue was migrated from Pagure Issue #14. Originally filed by jmagne (@jmagne) on 2011-11-15 03:17:43:

• Closed as None
• Assigned to jmagne (@jmagne)

Once a rough design has been agreed upon, early on it would be good to put together a reasonable proof of concept setup where we can demonstrate the use of some variant of the Realm technology to replace some of our existing authentication functionality in CS. For instance we could show that such a Realm could be used to authenticate a web servlet based on SSL client auth.

This issue was migrated from Pagure Issue #42. Originally filed by admiyo on 2011-11-17 19:00:12:

• Closed as Fixed
• Assigned to edewata (@edewata)

IAttrSet getElements() Returns an enumeration of the names of the attributes existing within this AttrSet. However, some places this is assumed to be an Enumeration of strings, and others mix in objects. The names should all be strings.

Read:
http://pki.fedoraproject.org/wiki/Building_Dogtag_10

Tried:

1. git clone [email protected]:dogtagpki/pki.git dogtagpki
2. cd scripts
3. ./compose_pki_core_packages rpms

Got:

error: Unable to open pki/specs/pki-core.spec: No such file or directory
ERROR:  'pki/specs/pki-core.spec' is missing!


Usage:  ./compose_pki_core_packages [options] <target>

        where <target> is one of the following:
...

This issue was migrated from Pagure Issue #7. Originally filed by admiyo on 2011-11-11 20:38:14:

• Closed as Duplicate
• Assigned to admiyo

It makes heavy use of sun.io.ByteToCharConverter

Either we should remove it or replace the cpde with something based around java.nio.charset. THis code is scheduled to be removed in Java 1.6

This issue was migrated from Pagure Issue #23. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:00:15:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

POST /pki/keyrequest/archive

• unpack parameters
• create an archival request (with relevant parameters in right place)
• get kra request queue
• add new request to queue
• return id of archival request

This issue was migrated from Pagure Issue #21. Originally filed by vakwetu (@vakwetu) on 2011-11-15 05:49:50:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

In particular transport cert. This would be the first interface implemented as it is a GET operation, and it does not require authentication.

For transport cert (for example):
GET /pki/config/kra/cert/transport

This issue was migrated from Pagure Issue #26. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:10:30:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

GET /pki/keys
GET /pki/keys/$id/details

This includes relevant search options as currently supported.

This issue was migrated from Pagure Issue #38. Originally filed by vakwetu (@vakwetu) on 2011-11-15 22:56:35:

• Assigned to jmagne (@jmagne)

This needs to be solved for both dogtag-future and 8.1/8.2

This issue was migrated from Pagure Issue #1. Originally filed by vakwetu (@vakwetu) on 2011-11-11 19:47:42:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

Add CS schema to IPA database. Resolve conflicts, indexing issues. Deprecate cmsuser? Add code to CS to allow use of users/roles instead of users/groups.

This issue was migrated from Pagure Issue #43. Originally filed by cfu (@cfu) on 2011-11-18 23:03:39:

• Closed as Fixed
• Assigned to cfu (@cfu)

write up ECC support for Dogtag:

• development phases
• detail on differences in mechanisms for each phase
• possibly setup instruction

Although there is heavy DRM involvement, components in TMS (TKS, TPS and smart card applets) are heavily involved as well, hence I selected "General" as Component.

This issue was migrated from Pagure Issue #10. Originally filed by admiyo on 2011-11-12 03:38:19:

• Closed as Fixed
• Assigned to admiyo

There is little reason to maintain our own collections, and a high likelihood of introducing bugs if we continue to do so. ArraySet should be replaced by one of the classes that implement Set, probably HashSet.

This issue was migrated from Pagure Issue #12. Originally filed by jmagne (@jmagne) on 2011-11-15 03:12:51:

• Closed as Fixed
• Assigned to jmagne (@jmagne)

Recent requirements have created the need to use our current DRM to manage symmetric keys and passphrases. Currently the DRM is used to archive and recover asymmetric private keys. The recovery process is somewhat of a heavyweight process involving Agent approvals and such. That process for the Token Management System is somewhat leaner since no live Agent intervention is required by humans. The following issues are apparent.

1. How will the keys and phrases be transported to and from the DRM? What will be the packaging?

2. How will this material actually be stored? The DRM already employs LDAP key records for private keys. Would we simply use a variation on this theme or use a completely different storage mechanism?

3. How will each symmetric key be uniquely identified? The current method uses its own mapping. How will we do this here?

4. Changes are afoot in the regular DRM with respect to ECC keys. How will these changes alter any plans to store symmetric keys.

5. How will the symmetric keys be wrapped and unwrapped during processing?

6. What kind of performance are we looking for here? In the current world, an archived key recovery can be considered somewhat of a rare operation necessitated by the loss of some data or whatnot. I suspect the retrieval of these symmetric keys might be done more often, based on the use cases.

This issue was migrated from Pagure Issue #28. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:26:09:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

POST /pki/keyrequest/recovery --> nAgents=1

This returns the key wrapped in the relevant secret. Do we want to do this? CSRF attack?

This issue was migrated from Pagure Issue #37. Originally filed by edewata (@edewata) on 2011-11-15 20:39:07:

• Closed as Fixed
• Assigned to edewata (@edewata)

Set up a machine to run CI tool such as Hudson to automatically build and run JUnit tests.

This issue was migrated from Pagure Issue #19. Originally filed by jmagne (@jmagne) on 2011-11-15 03:55:25:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

Based on the requirements agreed upon for using the DRM to store symmetric keys and passphrases, create a design on how this will be accomplished.

We’ve been using dogtag version 10.4 together with_jss_ version 4.4 on a up-to-date RHEL7 and Safenet HSMs for some years for handling SCEP requests.
We’re running into an issue again which we also had in the past: when using the HSM (a requirement here), only SCEP requests using DES for the encryption
can be decoded. When DES3 is used, dogtag throws an error with “could not unwrap PKCS10 blob”. With no HSM, both algorithms work.

However, the DES3 requests themselves are OK: we can unpack the inner pkcs#7, and decrypt the payload using ‘cmsutil’ (pointed at the nss db of the CA instance)
and read the pkcs#10 request within. So the HSM itself has no problem decrypting.

We also encountered this issue in the past with RHEL6 / DogTag 9, and it is still present with RHEL7 / Dogtag 10. At that time, we were able to configure the clients
to use DES to avoid the issue, but we can’t always dictate which algorithm the clients use,
and DES is nevertheless very weak.

It may still be related the old BZ: https://bugzilla.redhat.com/show_bug.cgi?id=825887 and be an issue with the FIPS-2 mode (which we are using)

It appears to be an issue with Dogtag. If someone has a suggestion or idea, we would appreciate hearing it.

Below you can find all needed parameters and config which we used.

• CA is an subca - (But dont matter, because the same issue occures also on an root ca)
• SCEP enrollment works with DES encryption (HSM attached)
• SCEP enrollment with DES3 works when NO hsm is used
• SCEP requests (DES + 3DES) can be decoded when using cmsutil direct against the HSM libary. (cmsutil -d /var/lib/pki/pkit-tomcat/alias -D -i inner_pkcs7_request.p7 -o request_des3.der )

CS.cfg

ca.scep.allowedEncryptionAlgorithms=DES3,DES
ca.scep.allowedHashAlgorithms=SHA1,SHA256,SHA512
ca.scep.enable=true
ca.scep.encryptionAlgorithm=DES3
ca.scep.hashAlgorithm=SHA1
ca.scep.nonceSizeLimit=16

SSECP call
./sscep enroll -u http://pki-test.example.com:8080/ca/cgi-bin/pkiclient.exe -c ca.crt -k local.key -r local.csr -l cert.crt -S sha1 -E 3des

debug.log

[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:263:init() CRSEnrollment: init: SCEP support is enabled.
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:264:init() CRSEnrollment: init: SCEP nickname: pkit04:caSigningCert cert-pkit04 CA
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:265:init() CRSEnrollment: init:   CA nickname: pkit04:caSigningCert cert-pkit04 CA
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:266:init() CRSEnrollment: init:    Token name: pkit04
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:267:init() CRSEnrollment: init: Is SCEP using CA keys: true
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:268:init() CRSEnrollment: init: mNonceSizeLimit: 16
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:269:init() CRSEnrollment: init: mHashAlgorithm: SHA1
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:270:init() CRSEnrollment: init: mHashAlgorithmList: SHA1,SHA256,SHA512
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:273:init() CRSEnrollment: init: mAllowedHashAlgorithm[0]=SHA1
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:273:init() CRSEnrollment: init: mAllowedHashAlgorithm[1]=SHA256
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:273:init() CRSEnrollment: init: mAllowedHashAlgorithm[2]=SHA512
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:275:init() CRSEnrollment: init: mEncryptionAlgorithm: DES3
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:276:init() CRSEnrollment: init: mEncryptionAlgorithmList: DES3,DES
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:279:init() CRSEnrollment: init: mAllowedEncryptionAlgorithm[0]=DES3
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:279:init() CRSEnrollment: init: mAllowedEncryptionAlgorithm[1]=DES
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:285:init() CRSEnrollment: init: mProfileId=caRouterCert
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:349:service() operation=PKIOperation
[03/Oct/2017:07:35:52][http-bio-8080-exec-1]: CRSEnrollment.java:351:service() message=MIIKywYJKoZIhvcNAQcCoIIKvDCCCrgCAQExCzAJBgUrDgMCGgUAMIIFnwYJKoZI
-...snip..
t3fqG6FkBAh3L1saONZJ0pfzOnnY5CZ4aJuf5ql3XA==
 
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: CRSEnrollment.java:920:handlePKIOperation() Processing PKCSReq
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: LdapBoundConnFactory.java:324:getConn() In LdapBoundConnFactory::getConn()
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: LdapBoundConnFactory.java:326:getConn() masterConn is connected: true
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: LdapBoundConnFactory.java:368:getConn() getConn: conn is connected true
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: LdapBoundConnFactory.java:398:getConn() getConn: mNumConns now 5
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: LdapBoundConnFactory.java:444:returnConn() returnConn: mNumConns now 6
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: CRSEnrollment.java:1164:unwrapPKCS10() failed to unwrap PKCS10 org.mozilla.jss.crypto.SymmetricKey$NotExtractableException
[03/Oct/2017:07:35:53][http-bio-8080-exec-1]: CRSEnrollment.java:385:service() ServletException javax.servlet.ServletException: Couldn't handle CEP request (PKCSReq) - Could not unwrap PKCS10 blob: null

localhost_access.log
10.10.10.10 - - [02/Oct/2017:11:09:27 +0200] "GET / ca / cgi-bin / pkiclient . exe ? operation = PKIOperation & message = MIIKzgYJKoZIhvcNAQcCoIIKvz...snip.. HTTP/1.0" 500 3071

localhost.log

SEVERE: Servlet.service() for servlet [caSCEP] in context with path [/ca] threw exception [Couldn't handle CEP request (PKCSReq) - Could not unwrap PKCS10 blob: null] with root cause
javax.servlet.ServletException: Couldn't handle CEP request (PKCSReq) - Could not unwrap PKCS10 blob: null
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.service(CRSEnrollment.java:386)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
        at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
        at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
        at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
        at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
        at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
        at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
        at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
        at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
        at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
        at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:748)

Comment by a java developer which has debugged the code and found that "issue" below. ( Thanks to MAT ).

In file CRSEnrollment.java in method unwrapPKCS10 the call delegation to the jss library fails gracefully at sk = kw.unwrapSymmetric( with the following excpetion:

[30/Oct/2017:07:49:15][http-bio-8080-exec-21]: failed to unwrap PKCS10 org.mozilla.jss.crypto.TokenException: Failed to unwrap key
[30/Oct/2017:07:49:15][http-bio-8080-exec-21]: ServletException javax.servlet.ServletException: Couldn't handle CEP request (PKCSReq) - Could not unwrap PKCS10 blob: Failed to unwrap key

The error comes clearly from the jss JNI library which is forwarded to the pki stack. I was not able to debug the code path. I tried to reproduce the use case in the jss library as well however it was not possible because the KeyWrapper class that is used here is marked as deprecated and shall be replaced by JCA. No test suite exists that tests the KeyWrapper even in very old relaeses of jss back to 2000 only the new JCA interface API is tested.

I hope you can provide a patch or a solution, because at the moment we are not able to issue certificates for clients which are using 3DES with scep.

Thanks in advanced.

BR
Flo

This issue was migrated from Pagure Issue #6. Originally filed by admiyo on 2011-11-11 20:18:16:

• Closed as Fixed
• Assigned to edewata (@edewata)

The policy framework has been deprecated, and replaced by the Profile framework. We should remove the policy framework and update code that references it to use the Profile framework, or remove the deprecation flag.

This issue was migrated from Pagure Issue #5. Originally filed by vakwetu (@vakwetu) on 2011-11-11 20:05:21:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

Write code to provide access to DB through certificates. Modify CS startup code to access DB through certs. The User should have access only to the CS suffix.

This issue was migrated from Pagure Issue #33. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:43:20:

• Assigned to nobody

• need to determine interface to ipa-ra-plugin from ipa
• requests will be agent authenticated.
• ipa will provide the challenge password

This issue was migrated from Pagure Issue #44. Originally filed by vakwetu (@vakwetu) on 2011-11-23 17:33:35:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

It has been decided that the code should go through an automatic reformatting to ensure that everything matches the project's coding standards.

Prior to this, we need to review the coding standards and confirm that they are what we want to use.

The current coding standards for the project are referenced here:
http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style
http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style

Some alternative styles:
http://freeipa.org/page/Coding_Style (C)
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java, sun conventions)

We should focus on the java coding style first, followed by C. The perl code is mostly going away most likely, so no need to focus on that.

IPA has a style guide for python, which, unless we have another compelling reason, we should probably use:

http://freeipa.org/page/Python_Coding_Style

This issue was migrated from Pagure Issue #29. Originally filed by vakwetu (@vakwetu) on 2011-11-15 06:28:13:

• Closed as Fixed
• Assigned to vakwetu (@vakwetu)

#No Description Provided