SHA-256 signed CMC revocation messages failing to verify on server
by Nimeh, Jamil
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
14 years
DogTag CS for CentOS or later Fedora Versions
by pki tech
Hi all,
Im planning to go for a Large scale CA implementation with Current DogTag
release 9.0 on Fedora 15. But the main worry that i have is the Fedora
Support Cycle, which makes an doubt on the security of the Systems at the
long run.
Are there anyone who has successfully deployed a complete CA, OCSP and RA
based solution on CentOS platform? If so I can continue my implementations
with CentOS. What I found while googling was there are package issues while
deploying DogTag over CentOS.
Although the main site says DogTag 9.0 is tested for up to only Fedora 15,
I found rpms for the subsystems pki-ca, pki-ocsp and pki-ra in other Fedora
repositories for example Fedora 16. So will it be possible to have a stable
PKI infrastructure over Fedora 16 with DogTag 9.0 (DogTag 10 is still in
alpha stage)
In the meantime I'm locally testing all the functionalities of DogTag 9.0
over Fedora 16 and CentOS. Will update as I progress.
Thank you.
14 years
Output plugin for binary cert/PKCS#7 response?
by Nimeh, Jamil
Hello Dogtag gurus,
I am currently experimenting with using sslget to submit PKCS#10s on a custom cert profile. Everything seems to be working well, but I always get back a big web page with the certificate or PKCS#10 buried in some javascript code. I've been doing grep/sed judo to get it out, but I was wondering if there was a way to get the response from the webserver to consist solely of the PKCS#7 or X.509 certificate in binary form? Is it something that is handled through an output plugin?
Thank you,
Jamil Nimeh
14 years
setting DNSName in subjectAltName extension
by Mike Helm
I need to set DNSName in server subjectAltname extensions, but
having difficulty getting the server's name into this field.
I've read this:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Certificate_System...
I can set the RFC822name value using this (see table B-15)
$request.requestor_email$
by making sure there's a requestor_email=something in the GET from the
RA. There really isn;t anything that corresponds to what DNSName should
be but I expected $request.subject$ would do; I added subject=some.thing.dom,
but no, I get "$request.subject$" as a literal string.
I also tried the obviously wrong example in Example B.1 (before the table) -
policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.SAN1$
same thing, $request.SAN1$ literal.
I can set subjAltExtPattern_1 to my own literal string, but obviously that's
counterproductive. I can set it to $request.requestor_email$ and get the email
address in DNSName - if I didn't have cases where BOTH subjectAltName fields
were needed I'd just re-purpose requestor_email.
So - what works and how? I'm stumped. Any ideas appreciated. Thanks, ==mwh
14 years