[PATCH] 694 Fixed illegal token state transition via TEMP_LOST.
by Endi Sukma Dewata
The TokenService.setTokenStatus() has been modified to restore
the temporarily lost token back into either uninitialized or
active state based on whether the token has certificates.
The TPSTokendb.tdbGetCertRecordsByCUID() has been modified to use
only tokenID attribute to search for token certificates more
accurately. It also has been simplified to return the certificate
records collection object directly.
Some constructors were added to the TPSException to allow chaining
the exception cause.
https://fedorahosted.org/pki/ticket/1808
--
Endi S. Dewata
8 years
Re: [Pki-devel] Design review request: RFC 2818 certificate compliance
by Fraser Tweedale
On Mon, Mar 07, 2016 at 07:33:52AM +0100, Jan Cholasta wrote:
> Hi,
>
> On 29.2.2016 07:59, Fraser Tweedale wrote:
> >Hi all (especially those interested in certificates),
> >
> >Please provide early review of my design for RFC 2818 compliance
> >which will address the following tickets:
> >
> >- #4970 Server certificate profile should always include a Subject Alternate name for the host
> >- #5706 [RFE] Support SAN-only certificates
> >
> >http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance
> >
> >The design is a WIP and there is no code for it yet. Looking for
> >feedback and (hopefully) validation of the approach before
> >committing cycles to implementing new profile components in Dogtag.
>
> 1) Do wildcard certificates need special handling? There is no mention of
> them in the design doc.
>
No special handling of wildcard certs is needed but I've added some
commentary to the design page.
> 2) Should we accept invalid CSR where CN length is greater than 64? I
> wouldn't be surprised if these existed in the wild.
>
Good question. I agree such CSRs probably exist. There are various
ways to handle them:
a) Reject request (with useful message; instruction to issue
SAN-only request instead)
b) Issue non-compliant cert with overlong CN. It will be helpful to
find out how important clients handle such certs.
c) Accept the CSR but "promote" the overlong CN from CSR into a SAN
dnsName, and issue a SAN-only cert. Some clients may not handle
such certs very well.
Personally I like (c), because the user intent is clear but we still
issue a valid cert, however, I expect there are clients out there
(particularly in "enterprise" environments?) that will not handle it
well.
I've copied pki-devel@ to solicit additional insights here :)
> 3) Sometimes it is not clear which parts belong to Dogtag and which to IPA
> itself. For example the upgrade section - I assume Dogtag should update
> registry.cfg and IPA caIPAserviceCert profile, but it is not clearly stated
> anywhere.
>
Thanks, I've added clarifying remarks. In brief: yes Dogtag should
update registry.cfg, but FreeIPA should update the profile.
Thank you for your feedback, Jan.
Fraser
8 years
[PATCH] JAVA_HOME for RHEL 6.8
by Ade Lee
Fix java_home and other 6.8 bugs
Fixes:
1. BZ 1306989 - Crash seen with pki-common pkg during IPA server install
Crash in upgrade script occurs because prior to configuration,
CS.cfg has lines that are comments and that do not parse neatly
into a foo=bar pattern. Now, we will ignore comments and blank lines.
2. BZ 1290535 - Check for incompatible Java at startup
The bulk of this change. Sets the JAVA_HOME to the 1.7.0 JRE.
rather than relying on alternatives. Also includes migration script
for existing instances.
3. BZ1313207 - ca.subsystem.certreq missing from CS.cfg
certreq is not really needed right now for the upgrade scripts.
This will ignore the error if it is not present.
Please review,
Ade
8 years
[PATCH] - Miscellaneous Cleanup of spec files
by Matthew Harmsen
Please review the attached patch which cleans up some of the spec files
including removing javadocs from the 'meta' package and renaming DRM to KRA.
Thanks,
-- Matt
8 years
[PATCH] 0060 Package pki client library for Python 3
by Christian Heimes
The patch implements https://fedorahosted.org/pki/ticket/1739.
We have a bit of a chicken and egg problem. The pki-upgrade command
depends on Python 2 code. Ade suggested to have both Python 2 and 3 code
in pki-base. The approach has the disadvantage to pull in python3
dependencies like python3-nss, python3-requests and python3-six.
The patch uses a different approach:
- new package 'pki-base-python3' depends on 'pki-base'
- 'pki-base' now also provides 'pki-base-python2'
You still can't have pki-base-python3 without pki-base-python2 but you
can have pki-base-python2 without Python 3. Once we switch to Python 3
for pki.server (10.4?), we can switch dependencies and have
pki-base-python2 as extra package.
Christian
8 years
[PATCH] 0057-0059 RHEL fixes and preparations for Python 3
by Christian Heimes
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
8 years