Here is the first (rough) cut of IEC 62351-8 (IECUserRoles)
extension support and a DNP3 profile that makes use of it. This is
to meet (some of) the PKI needs for the "Smart Grid" DNP3 Secure
Authentication v5 (SAv5) standard.
In brief, the SN and all the IECUserRoles params will be given in
profile inputs, and the key is taken from a CertReqInput.
There's still a bit of work to go - notably, some of the
IECUserRoles fields are unimplemented, and some of those that *are*
implemented are not yet read out of the profile input but rather are
hardcoded. The extension *does* appear on the certificate, so I
should get that all completed tomorrow.
The RAEnrollProfile class is not used or referenced anywhere in the
codebase. I presume it was related to the RA, but even immediately
before removal of the RA it did not seem to be used, so it seems
safe to remove it.
The first major patch for lightweight sub-CAs is attached for
review. Some important features are not yet implemented in this
- Sub-CA creation
- Caching of sub-CA instances
- Signing key replication for clones
- CRLs (the OCSP servlet works for sub-CAs, however)
- Sub-CA support is possibly missing from some web servlets /
templates. Let me know if you hit any.
Because sub-CA creation is not implemented, if you want to test this
patch you will need to:
1. Use the top-level CA to sign a sub-CA certificate and manually
install it in the NSSDB with the nickname:
2. Create the sub-CA certificate repository OU:
3. When submitting requests or other queries via HTTP, edit the
initial link target or form action to include the query parameter:
(Subsequent pages should not require this intervention.)
I have also updated the design proposal with some refinements and
details of the implementation so far:
Looking forward to your feedback / bug reports!
New pki-server CLI commands have been added to migrate the server
configuration from Tomcat 7 to Tomcat 8 and vice versa. These
commands can be used later during system upgrade to migrate
existing instances from Tomcat 7 in F22 to Tomcat 8 in F23.
The Python CLI framework has been refactored to provide a way to
find other CLI modules by the command names.
Endi S. Dewata
The Dogtag code has been modified to support both Tomcat 7 and 8.
All files depending on a specific Tomcat version are now stored
in separate folders. The build scripts have been modified to use
the proper folder for the target platform. The tomcatjss
dependency has been updated as well.
The upgrade script will be added in a separate patch.
Endi S. Dewata
I've been accumulating drive-by cleanups and other small supporting
changes during my sub-CAs work. To improve the signal-noise ratio
and reduce the burden of reviewing the feature, I'm going to submit
some of these cleanups separately for review/merge beforehand.
Here's the first few.
Please review the attached patch which implements the simple fix
documented in the following issue:
* PKI TRAC Ticket #1284 - pkispawn URL redirect issue
This patch was tested on an x86_64 machine running Fedora 21.
Along with LDAP profiles, we will be adding modules to the CLI for
adding and editing profiles in the ConfigStore format that was used
for file-based profiles. For more info, see:
There is an existing CLI for adding and modifying profiles, in the
XML format, e.g. ``pki ca profile add caCustomProfile.xml``. The
XML format carries information including the profile ID and
class_id, but these data must be supplied out-of-band when dealing
with the ConfigStore format.
Because of this, I intend to:
- add new commands to the existing profile CLI for working with the
"raw" (i.e., ConfigStore) format, e.g. "edit-raw", "add-raw".
Where necessary, these commands will take compulsory
``--profile-id`` and/or ``--class-id`` arguments, to account for
the absense of such information in the profile ConfigStore format;
- transport this information in the XML format - not in the "raw"
format - so that it will be unnecessary to make changes to
ProfileClient or the ProfileService API.
As usual, I welcome feedback - especially if you feel I am going the
wrong way ^_^
This is the first cut of the LDAP profile change monitoring. It
depends on patches 0004..0009 and 0014
To summarise the implementation: a separate thread carries out a
persistent LDAP search and calls back into the ProfileSubsystem when
changes occur. I haven't had much experience with persistent
searches or multithreaded programming in Java, so eyeballs familiar
with those areas are needed.
I haven't yet tested with changes replicating between clones (a task
for tomorrow) but I wanted to get the patch on list for feedback as
early as possible.