Configurable Subject Alt Name in Cert Profile?
by ryan.millay＠gdc4s.com
RHEL 5.8
Red Hat CS 8.1
I'm hoping this should be a relatively straight forward question and
others have run into something similar:
When generating a certificate, is it possible to dynamically include/not
include the Subject Alt Name field based on an LDAP parameter? When
looking at the certificate profile there's a "subjAltExtGNEnable"
parameter, but I don't believe that can be set to a request parameter,
like $request.includeSAN$ for example, based on the testing I've done.
Assuming that the "subjAltExtGNEnable" field must be static text,
perhaps there is another work around. If included, the Subject Alt Name
in this case would represent a user's full DN. If not included, the
request parameter could be left blank and the Subject Alt Name would be
empty. Here's a little snippet from the cert profile:
policyset.CSCertSet.7.constraint.class_id=noConstraintImpl
policyset.CSCertSet.7.constraint.name=No Constraint
policyset.CSCertSet.7.default.class_id=subjectAltNameExtDefaultImpl
policyset.CSCertSet.7.default.name=Subject Alternative Name Extension
Default
policyset.CSCertSet.7.default.params.subjAltExtGNEnable_0=true
policyset.CSCertSet.7.default.params.subjAltExtGNEnable_1=false
policyset.CSCertSet.7.default.params.subjAltExtGNEnable_2=false
policyset.CSCertSet.7.default.params.subjAltExtGNEnable_3=false
policyset.CSCertSet.7.default.params.subjAltExtGNEnable_4=false
policyset.CSCertSet.7.default.params.subjAltExtPattern_0=$request.pkispo
nsordn$
policyset.CSCertSet.7.default.params.subjAltExtPattern_1=
policyset.CSCertSet.7.default.params.subjAltExtPattern_2=
policyset.CSCertSet.7.default.params.subjAltExtPattern_3=
policyset.CSCertSet.7.default.params.subjAltExtPattern_4=
policyset.CSCertSet.7.default.params.subjAltExtType_0=DirectoryName
policyset.CSCertSet.7.default.params.subjAltExtType_1=RFC822Name
policyset.CSCertSet.7.default.params.subjAltExtType_2=RFC822Name
policyset.CSCertSet.7.default.params.subjAltExtType_3=RFC822Name
policyset.CSCertSet.7.default.params.subjAltExtType_4=RFC822Name
policyset.CSCertSet.7.default.params.subjAltNameExtCritical=false
The issue that arises here is the CA fails with an IO exception from the
$request.pkisponsordn$ format. That value is a user DN, similar to
CN=FIRSTNAME.LASTNAME, OU=ORGANIZATION, OU=ORGANIZATION2, O=COUNTRY,
C=COUNTRYCODE. The CA's debug log shows the '=' and the ',' being
escaped by backslashes. The CA then fails to populate the Subject Alt
Name due to the following error:
SubjectAltNameExtDefault: populate java.io.IOException: Unknown AVA
keyword 'CN\'.
Is there a way to properly escape the user DN so it can be used in the
Subject Alt Name? Again, the ultimate goal being the user DN could be
populated or not. If populated, it is included as the Subject Alt Name.
If not populated, the Subject Alt Name is left blank when the
certificate is generated.
Thank you,
Ryan Millay
13 years
- 2
- 1
Announcing Dogtag 10.0.1 for pki-core and dogtag-pki
by Ade Lee
The Dogtag team is proud to announce the first errata build for
Dogtag v10.0.0.
The only packages that are being modified are dogtag-pki and pki-core,
both of which are being released as version 10.0.1.
A build is available for Fedora 18 in the updates-testing repo. Please
try it out and provide karma to move it to the F18 stable repo.
Daily developer builds for Fedora 17 and 18 are available at
http://nkinder.fedorapeople.org/dogtag-devel/fedora/
== Build Versions ==
pki-core-10.0.1-1.fc18
pki-ra-10.0.0-1.fc18
pki-tps-10.0.0-1.fc18
dogtag-pki-10.0.1-1.fc18
dogtag-pki-theme-10.0.0-1.fc18
pki-console-10.0.0-1.fc18
== Highlights since Dogtag v. 10.0.0 ==
* Nonces have been added to the RESTful interface for certificate
revocation to preventing cross site scripting attacks on that interface.
* A new servlet has been added to the RESTful interface to add and
remove KRA connector configuration from a CA. This is used to clean up
a CA when a KRA is destroyed.
* The default validity of the CA signing cert has been lengthened from 8
to 20 years.
* pkispawn has been modified to allow the user to specify the location
of the generated admin cert PKCS#12 file.
* OCSP now supports ECC CRLs.
* A more robust use of interpolation has been added to pkispawn.
* pkidaemon has been repaired to display the runtime status of PKI
Java-based instances
* A third-party license file has been added for Dogtag 10's use of
JQuery and the JQuery.i18n.properties plug-in
== Detailed Changes since Dogtag v. 10.0.0 ==
alee (12):
- TRAC Ticket 367 - pkidestroy does not remove connector
- Fix spec file to allow f17 to work with latest tomcatjss
- TRAC Ticket 466 - Increase root CA validity to 20 years
- TRAC Ticket 437 - Make admin cert p12 file location configurable
- TRAC Ticket 393 - pkispawn fails when selinux is disabled
- Punctuation and formatting changes in man pages
- TRAC Ticket 436 - Interpolation for pki_subsystem
- TRAC Ticket 433 - Interpolation for paths
- TRAC Ticket 435 - Identical instance id and instance name
- TRAC Ticket 406 - Replace file dependencies with package dependencies
- Revert to using default config file for pkidestroy
- Hardcode setting of resteasy-lib for instance
cfu (1):
- Bugzilla Bug 839426 - [RFE] ECC CRL support for OCSP
edewata (3):
- TRAC Ticket 214 - Missing error description for duplicate user
- TRAC Ticket 213 - Add nonces for cert revocation
- TRAC Ticket 191 - Mapping HTTP Exceptions to HTTP error codes
mharmsen (4):
- TRAC Ticket #430 - License for 3rd party code
- TRAC Ticket 469 - Fix tomcatjss issue in spec files
- TRAC Ticket 468 - pkispawn throws exception
- TRAC Ticket 271 - Dogtag 10: Fix 'status' command in 'pkidaemon'
13 years
- 1
- 0
Announcing the release of Dogtag 10
by Ade Lee
The Dogtag team is proud to announce the release of Dogtag v10.0.0.
This release is being bundled with the GA release of Fedora 18, and
marks the culmination of over a year of development by the Dogtag team.
== Build Versions ==
pki-core-10.0.0-2.fc18
pki-ra-10.0.0-1.fc18
pki-tps-10.0.0-1.fc18
dogtag-pki-10.0.0-1.fc18
dogtag-pki-theme-10.0.0-1.fc18
pki-console-10.0.0-1.fc18
== Upgrade Notes ==
It is possible to upgrade from a Dogtag 9 instance by first upgrading
your server to Fedora 18 and then updating the Dogtag software.
Existing Dogtag instances will continue to work correctly using existing
instances, with the Java-based instances running on Tomcat 6.
However, because the new functionality and interfaces depend on instance
configuration, these will not be available to existing Dogtag 9-style
instances. To take advantage of these new features, new Dogtag 10
instances should be created.
Documentation will soon be provided on how to migrate a Dogtag 9 - style
instance to a new Dogtag 10 instance.
== Highlights since Dogtag v. 9 ==
Infrastructure and Development Changes:
* The Dogtag code base was moved to git from svn.
* Java development is now done under Eclipse.
* Dogtag 10 uses its own public-facing TRAC project
management system.
* Improvements were made to CMake modules for Java development.
* Java development uses OpenJDK 7.
* Python development uses Python 2.7 and Jython 2.2.
* Dogtag 10 Java-based instances run on Tomcat 7.
* Dogtag 10 RA and TPS instances run on Apache 2.4.
Refactoring and Cleanup:
* Code has been reformatted to uniform formatting and coding standards.
* Based on feedback provided by Eclipse and Coverity, the following
types of cleanup occurred:
** Removal of dead code and unnecessary code blocks.
** Removal of generic containers and implementation of type safety.
** Removal/ replacement of deprecated code, with the addition of JUnit
tests to confirm correctness.
** Address various memory leaks and corruption issues, coding style
issues etc.
* The Dogtag code pre-dates many of the modern Java utilities to do
encoding, HTTP and XML parsing etc. As a result, custom code was
written to do these functions. This code has been replaced with
standard code, and a whole package (osutil) was eliminated.
REST Interface:
To allow easier and more intuitive interaction with the Dogtag servers,
a new REST interface has been added. This interface is based on
RESTEasy framework, a fully certified implementation of the JAX-RS
specification. Clients interact with this framework using intuitive
REST URLs, and using standard XML or JSON inputs.
Included is a Java client proxy framework which can be used by client
applications to build HTTP requests on the Dogtag servers, simply by
invoking methods on the client objects. This client framework is used
in the new command line interface "pki" as described below.
The plan is to continue over time to extend the REST interface to cover
all of the essential Dogtag functionality. In this release, the
following functionality has been implemented:
* With a CA:
** Create, review and approve certificate requests.
** List, view, revoke, hold and release certificates.
** Get installation token from security domain
** Add/remove KRA connector configuration
** Retrieve and list certificate profiles
* With KRA:
** Retrieve transport certificate
** List/ archive and recover symmetric keys
* With all Java systems:
** Add/Remove/Modify/View users, groups and group members
** Start system installation service
Third-party Components:
* Dogtag 10 includes JQuery and the Jquery.i18n.properties plug-in.
CLI:
* A new intuitive command line interface has been created, based on the
RESTEasy client framework. This allows administrators and agents to
perform all of the operations exposed by the REST interface from the
command line, or from scripts.
Storage of symmetric keys in the DRM:
* The DRM provides secure encrypted storage for asymmetric keys. The
KRA has been extended to provide a mechanism to securely archive and
recover symmetric keys. This would be useful for storing disk
encryption keys for instance.
SELinux changes:
* In Dogtag 9, we maintained a custom SELinux policy to provide
mandatory access controls for interactions with the Dogtag server. In
Dogtag 10, this policy has been cleaned up, simplified and integrated
into the system base policy. As a result, the pki-selinux package has
been retired.
ECC:
* In earlier releases, Dogtag only supported ECC certificate issuance
when the CA was connected to an ECC-capable external crypto token. In
Dogtag 10, all CS servers (CA, OCSP, DRM, TKS, TPS) can now be issued
ECC certificates and run in such environment that:
** CS servers can communicate securely with ECC SSL certificates.
** Administrators and agents can access their administration ports via
SSL using ECC certificates
** ECC encryption certificates can now have their private keys archived
(and recovered) by the DRM. For this feature, we used an
ECC-capable HSM in our development and QE environment on the client
side for development and testing. Certicom software tokens could
not be used because of an issue with malformed private keys.
** The TMS testing client tool, tpsclient, can now be used to test
token-based enrollment and key archival in the TMS environment (the
actual smart card support will follow in a later release)
New Installer:
* New installer tools (pkispawn, pkidestroy) has been written in Python
to create Dogtag Java-based instances (CA, KRA, OCSP, TKS). Over time,
this installer will be extended to handle the remaining Apache-based
instances (TPS and RA), and pkicreate/pkiremove/pkisilent will be
retired and removed.
* pkispawn performs the same operations that pkicreate and the pkisilent
used to do, meaning that a Dogtag Java-based instance can be installed
and configured in a single non-interactive step. With the right
options, though, it is still possible to configure an instance by going
through the web-based installation UI panels.
New Directory Layout/ Architecture/ Standard Ports
* It is now possible (though not required) to install multiple Java
subsystems (CA, KRA, TKS, OCSP) within a single tomcat instance. This
is useful for small deployments where, for example, you might want
leverage the capabilities of a CA and KRA on a single server. In
keeping with this change, the directory structure of a Dogtag instance
has changed.
* By default, Dogtag will install on the default tomcat ports (8443 and
8080). There will no longer be any separation of EE, admin and agent
interfaces on different ports.
Package Restructuring:
* The Dogtag RPM packages have been restructured to reduce the number of
packages and more accurately separate client and server components. The
current packages are:
** pki-base: code common to clients and server
** pki-tools: Java and native tools used by client and server.
** pki-server: code used by Java servers, only on the server.
** pki-ca, pki-kra, pki-ocsp, pki-tks, pki-ra, pki-tps: subsystem
specific code
** pki-javadoc: consolidation of the pki-common-javadoc,
pki-java-tools-javadoc, and pki-util-javadoc packages
** pki-symkey: provides native symmetric key operations
** pki-console: administrative tool for CA, KRA, OCSP, and TKS
* The UI packages have been rearranged and consolidated to make
customizing an instance's user interfaces more straightforward, and to
ensure a more consistent look and feel across subsystems. All of the
subsystem-specific UI packages have been eliminated, and there is now
a single UI package (dogtag-pki-server-theme) which contains all the CSS
style sheets, image files and properties files for all subsystems. A
customer wanting to customize the UI could simply replace the components
in this package. Additionally, the pki-console requires its own UI
package, dogtag-pki-console-theme.
* A meta-package (dogtag-pki) has been created to conveniently install
all existing Dogtag 10 PKI packages.
13 years
- 1
- 0
Problems with Dogtag and CA cert signed by External CA
by Dwayne MacKinnon
Hi all,
A helpful fellow called alee on #dogtag-pki suggested I write the list. I've
been playing with dogtag-pki-9.0.0-10 on 64-bit Fedora 17.
I'm looking to use dogtag to run a subordinate CA that does all our everyday
PKI stuff. So when I used pki-create and went into the webform, I went the
"create a csr" route and signed it using a root CA I'd set up using openssl.
Everything seemed to work out fine, until I got to the point where I was
restarting pki-cad (using systemctl restart pki-cad(a)pki-ca.service). It
wouldn't start.
With alee's help I tracked it down to a failure of SystemCertsVerification
during the selftests.
He asked me to submit my debug log to the list, so here it is.
Cheers,
DMK
13 years
- 4
- 4
- ← Newer
- 1
- Older →