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?
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
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
In the meantime I'm locally testing all the functionalities of DogTag 9.0
over Fedora 16 and CentOS. Will update as I progress.
Hello Dogtag gurus,
I need to set DNSName in server subjectAltname extensions, but
having difficulty getting the server's name into this field.
I've read this:
I can set the RFC822name value using this (see table B-15)
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) -
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