Request to build pki-core-9.0.3-26.el6 for RHEL 6.4 in Brew . . .
by Matthew Harmsen
We would like to request an official build of 'pki-core-9.0.3-26.el6'
for RHEL 6.4 in Brew to resolve the following bugs:
*
*Bugzilla Bug #841663*
<https://bugzilla.redhat.com/show_bug.cgi?id=841663>-serial number
incorrectly cast from BigInt to integer in installation wizard
* *Bugzilla Bug #844459*
<https://bugzilla.redhat.com/show_bug.cgi?id=844459>-Increase audit
cert renewal range to 2 years
* *Bugzilla Bug #858864*
<https://bugzilla.redhat.com/show_bug.cgi?id=858864>-create/
identify a mechanism for clients to determine that the pki subsystem
is up
The official source tarball and all associated patches are located at:
* http://pki.fedoraproject.org/pki/sources/pki-core/
and include the following:
* pki-core-9.0.3.tar.gz
* pki-core-9.0.3-r1846.patch
* pki-core-9.0.3-r1860.patch
* pki-core-9.0.3-r1862.patch
* pki-core-9.0.3-r1864.patch
* pki-core-9.0.3-r1875.patch
* pki-core-9.0.3-r1879.patch
* pki-core-9.0.3-r1886.patch
* pki-core-9.0.3-r1908.patch
* pki-core-9.0.3-r2074.patch
* pki-core-9.0.3-r2097.patch
* pki-core-9.0.3-r2103.patch
* pki-core-9.0.3-r2104.patch
* pki-core-9.0.3-r2106.patch
* pki-core-9.0.3-r2112.patch
* pki-core-9.0.3-r2118.patch
* pki-core-9.0.3-r2125.patch
* pki-core-9.0.3-r2126.patch
* pki-core-9.0.3-r2128.patch
* pki-core-9.0.3-r2149.patch
* pki-core-9.0.3-r2151.patch
* pki-core-9.0.3-r2153.patch
* pki-core-9.0.3-r2161.patch
* pki-core-9.0.3-r2163.patch
* pki-core-9.0.3-r2182.patch
* pki-core-9.0.3-r2249.patch
* pki-core-9.0.3-bz771790.patch
* pki-core-9.0.3-bz745677.patch
* pki-core-9.0.3-bz769388.patch
* pki-core-9.0.3-bz802396.patch
* pki-core-9.0.3-bz819111.patch
* pki-core-9.0.3-bz841663.patch
* pki-core-9.0.3-bz844459.patch
* pki-core-9.0.3-bz858864.patch
The updated official spec file is attached.
Thanks,
-- Matt
12 years, 6 months
Announcing Dogtag 10.0.0 beta 1 release
by Ade Lee
The Dogtag team is proud to announce version Dogtag v10.0.0 beta 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.0-0.43.b1.fc18
pki-ra-10.0.0-0.9.b1.fc18
pki-tps-10.0.0-0.9.b1.fc18
dogtag-pki-10.0.0-0.10.b1.fc18
dogtag-pki-theme-10.0.0-0.2.b1.fc18
pki-console-10.0.0-0.8.b1.fc18
== Highlights since Dogtag v. 10.0.0 alpha 2 (Oct 1 2012) ==
* Merged pki-silent into pki-server.
* Added Provides to packages replacing obsolete packages.
* Added needed link for updated d9 -> d10 instances. Found in IPA
testing.
* Backed up CS.cfg before upgrading from d9 -> d10
* New selinux policy for all components. The Java components now take
advantage of a tomcat domain defined in the base selinux policy, and
the RA/TPS policies have been cleaned up considerably. The policy that is
now delivered is very close to the final version that will be delivered
in the base policy. That will be a deliverable for beta 2.
* Selinux context for startup scripts for all components set so that
runcon is not required.
* Cleaned up lock and pid files generation and removal for java
processes.
* Rebuilt packages against the latest F18 base selinux policy packages
to resolve an issue in installing pki-selinux due to removal of a
boolean in F18 base selinux policies. This issue was reported by IPA.
== Notes for F17 ==
* F17 requires an selinux version that is still in updates-testing.
Enable this repo to upgrade accordingly.
* F17 tomcat has a bug in the way it handles pid files.
https://bugzilla.redhat.com/show_bug.cgi?id=863307. Prior to creating
an instance, you need to perform the following workaround:
In the file, /usr/sbin/tomcat-sysd, change the line:
export CATALINA_PID="/var/run/${NAME}.pid"
to:
export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}"
== Feedback ==
Please provide comments, bugs and other feedback via the pki-devel
mailing list: http://www.redhat.com/mailman/listinfo/pki-devel
== Detailed Changelog ==
Ade Lee (11):
5ef10ba Update selinux-policy version to fix error from latest policy
81596ba fix spec typo
919434b Added build requires for version of selinux-policy-devel
5014442 Update release to b1
9cd11bc Fix name of CS.cfg backup file
63237d3 Backup CS.cfg before d10 update
da73f97 Changes to start pki_ra and pki_tps in correct context
6e79c7c add selinux context for pkidaemon, remove unneeded pid/lock code
f542060 move common policy into tps, ra templates
dbc6dec Use the tomcat selinux domain for the Java processes
3d5dc3b Added needed link for updated d9 -> d10 instances
Endi Dewata (3):
23c70bd Merged pki-silent into pki-server.
79a3d82 Renamed "shared" folder to "server".
753d55e Added Provides to packages replacing obsolete packages.
12 years, 6 months
Re: [Pki-devel] [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server
by Christina Fu
Hi Jamil,
We branched off of JSS 4.2.6 and created several patches ever since.
Merging with upstream JSS (4.3) has been planned to be done within the
next year also. Until then, we are not able to provide information with
confidence on how JSS4.3 would work with our current releases. If any
Dogtag community member has tried and has answer for you, it would be
great.
Christina
On 10/10/2012 09:54 AM, Nimeh, Jamil wrote:
>
> [Re-reply to include pki-devel(a)redhat.com <mailto:pki-devel@redhat.com>]
>
> Hi Christina, sorry for taking so long to get back to you. I can file
> this against JSS, but given that it's a down-rev version (4.2.6) and
> appears to be fixed in JSS 4.3, is it worth filing this?
>
> I guess the bigger question that affects SHA-2 algorithms as they are
> implemented in Dogtag is whether or not I can safely use JSS 4.3 with
> Dogtag 9.0.x? 4.2.6 is what appears to be the latest rev in the F15
> yum repositories. Do you (or anyone on your team maybe) know if there
> are incompatibilities between JSS 4.2.6 and 4.3 that would break a
> Dogtag 9 installation?
>
> If it can work the areas that this would affect would be:
>
> * Proper creation of SCEP CertRep messages when using SHA-2 algs
> * The ability to sign OCSP responses using something other than
> SHA-1 (can that be changed? I don't see a tuneable for this)
> * The ability to submit CMC revocation messages using SHA-2 and
> have it properly validated before acting on it in the CA.
>
> There might be other areas as well (maybe in other CMC related
> functions) but those three areas are the ones I've run into.
>
>
> Thanks,
>
> Jamil
>
> ------------------------------------------------------------------------
> *From:* pki-users-bounces(a)redhat.com [pki-users-bounces(a)redhat.com] on
> behalf of Christina Fu [cfu(a)redhat.com]
> *Sent:* Monday, October 01, 2012 1:22 PM
> *To:* pki-users(a)redhat.com
> *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages
> failing to verify on server
>
> Hi Jamil,
>
> I see the issue now. I agree there is an issue with the OID. In
> fact, the hashalg (2) is missing from not just SHA256, but also SHA384
> and SHA512 as well.
>
> Please go ahead and file a bug for JSS so it could be scheduled for
> future release. It will probably be automatically assigned to me by
> default.
>
> thanks,
> Christina
>
> On 09/27/2012 09:34 AM, Christina Fu wrote:
>> Hi Jamil,
>>
>> I am running a variant of jss-4.2.6-23 (with one extra patch that I
>> have not had time to push/build, but it has nothing to do with your
>> suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I
>> develop on RHEL.
>>
>> Yes, if you'd send in your code with precise reproducing steps, I
>> might be able to look into it sooner.
>>
>> Christina
>>
>> On 09/25/2012 11:10 PM, Nimeh, Jamil wrote:
>>> Hi Christina, thank you very much for getting back to me.
>>>
>>> I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID.
>>> That seems to work across the board with JSS and Dogtag (otherwise I
>>> could never sign a cert with SHA-256, I suppose). I'd be curious to
>>> know what version of JSS is on your RHEL/RHCS8.1 machine, and
>>> perhaps what NSS version. On my Fedora box it's JSS 4.2.6 and NSS
>>> 3.13.4. Maybe something different between the bits we're running?
>>>
>>> I've run into the issue when a PKCS#7 or CMS signedData message is
>>> created. In those cases, the SHA-256 OID would normally be asserted
>>> in two locations:
>>> 1. In the DigestAlgorithmIdentifiers segment of the SignedData
>>> object (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly
>>> asserted here.
>>>
>>> 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see
>>> RFC 5652 5.3): This is where the OID gets messed up with SHA-2
>>> algs. Since there is only one signer, the
>>> DigestAlgorithmIdentifiers section at the beginning would have only
>>> one OID, the SHA-256 one, and that OID should be repeated again in
>>> the SignerInfo.
>>>
>>> What happens though is that the SignerInfo's
>>> DigestAlgorithmIdentifier will show up with an OID of
>>> 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This
>>> appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6
>>> is what comes down when the dogtag packages are pulled with yum, so
>>> I wasn't sure if I could pop in a newer JSS safely.
>>>
>>> Tomorrow I'll take my doctored up CMCRevoke and cook up two
>>> messages, one where I load the 4.2.6 JSS and one where I do 4.3 and
>>> I'll send you the DER encodings so you can see what I'm talking
>>> about. I don't recall, but I think the bug report for 824624 might
>>> have sample SCEP CertRep messages from the CA, which show the issue
>>> using PKCS#7.
>>>
>>> Once again, thank you very much for taking the time to look at this.
>>>
>>> --Jamil
>>>
>>> ------------------------------------------------------------------------
>>> *From:* pki-users-bounces(a)redhat.com [pki-users-bounces(a)redhat.com]
>>> on behalf of Christina Fu [cfu(a)redhat.com]
>>> *Sent:* Tuesday, September 25, 2012 8:46 PM
>>> *To:* pki-users(a)redhat.com
>>> *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages
>>> failing to verify on server
>>>
>>> Hi Jamil,
>>>
>>> I tried to reproduce your issue, but I seemed to be able to generate
>>> CMC revocation request with SHA-256 digest. I have to admit that my
>>> main development machine is RHEL and I work on RHCS8.1 tree.
>>>
>>> I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the
>>> exception with DSA), compiled, and it just worked. Did you do
>>> anything different?
>>>
>>> I could see in dumpasn1 where SHA245 is in place:
>>> C-Sequence (13)
>>> Object Identifier (9)
>>> 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption)
>>> NULL (0)
>>> Christina
>>>
>>> On 09/19/2012 11:19 AM, Christina Fu wrote:
>>>> Hi Jamil,
>>>>
>>>> We made an effort to support SHA2 where we can but might have
>>>> missed a few places. I'll look into this and hopefully be able to
>>>> get back to you in a few days.
>>>>
>>>> thanks,
>>>> Christina
>>>>
>>>> On 09/19/2012 12:44 AM, Nimeh, Jamil wrote:
>>>>>
>>>>> Hello Dogtag Gurus,
>>>>>
>>>>> I have been trying to issue CMC revocation messages signed with
>>>>> SHA-256, but the server fails to validate the message in the
>>>>> CMCAuth java policy module. If I leave all fields the same but
>>>>> change the signature algorithm to SHA-1 then everything seems to
>>>>> work fine.
>>>>>
>>>>> I suspect this is another side-effect of the root-cause for bug
>>>>> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7
>>>>> messages are created using any of the SHA-2 variants, the OIDs get
>>>>> messed up. This happened with SCEP responses from the CA (the bug
>>>>> referenced above) and I had it happen with the CMC revoke
>>>>> modifications I made. The latter issue was fixed by pulling down
>>>>> JSS 4.3 and loading that jar in the classpath for the modified
>>>>> CMCRevoke tool. However, on the server side I ended up seeing
>>>>> verification failures.
>>>>>
>>>>> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one
>>>>> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with
>>>>> JSS 4.3 or later. Is that still the case with the latest 9.0
>>>>> packages?
>>>>>
>>>>>
>>>>> Has anyone had any success generating these CMC messages using
>>>>> SHA-2 hash algs and getting Dogtag to accept them?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jamil
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pki-users mailing list
>>>>> Pki-users(a)redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pki-users
>>>>
>>>>
>>>> _______________________________________________
>>>> Pki-users mailing list
>>>> Pki-users(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-users
>>>
>>
>>
>> _______________________________________________
>> Pki-users mailing list
>> Pki-users(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-users
>
12 years, 6 months
[PATCH] 66 - selinux changes for pki_tomcat_cert_t
by Ade Lee
Added some missing selinux rules found during ipa installation, as well
as a new type pki_tomcat_cert_t for the NSS certificate databases.
Added an selinux interface and permissions for certmonger to read and
write to those files.
Also added the pkispawn and pkidestroy logic to label files for
non-default instances.
I have pushed to master so that IPA can test the changes from the
nightly build, and so that mgrepl can get the latest policy to do a test
scratch build in the morning. But please review notwithstanding.
Ade
12 years, 6 months
PATCH - 65 - backup CS.cfg befor d10 update
by Ade Lee
pviktorin had a weird (and unreproduced) case, where during an upgrade
from d9 -> d10, and ipa 2.2 -> ipa 3, the CS.cfg was blanked.
As a temporary mitigation step in case this happens again, we will save
the old CS.cfg when the update steps are performed.
Ade
12 years, 6 months
[PATCH] 60-63 revised selinux policy
by Ade Lee
Apply patches in order.
This adds the selinux policy which is likely to be added to the system
policy for all subsystems. Please try it out in permissive mode and
note any avcs generated.
Also includes:
- required code to get ra and tps instances started.
- cleanup code for pid file management for the java subsystems
Notes:
1. On f18, everything works as expected.
2. On f17, there are two issues
a) the needed selinux-policy has been built in koji but is not in
updates yet. I will bug mgrepl about this in the morning.
b) the pid file fixes will break java subsystem startup because of a bug
in tomcat. https://bugzilla.redhat.com/show_bug.cgi?id=863307
I will be pushing for this to be fixed asap. In the meantime, you will
need to modify /usr/sbin/tomcat-sysd and replace
export CATALINA_PID="/var/run/${NAME}.pid"
with:
export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}"
Ade
12 years, 6 months
