reset pkiconsole password [for CA server]
by Nalinda Herath
Dear All,
Is there a possibility to reset the pkiconsole password for the default
"admin" user? I'm referring to the pkiconsole for the CA instance. (not
the console for the Directory Server)
Nalinda
--
----
Nalinda Herath
Information Security Engineer
TechCERT / A Division of LK Domain Registry,
545/4, De Soysa Rd., Molpe,
Moratuwa 10400,
Sri Lanka
Mobile: +94 77 7303905
Office: +94 11 4216062
Fax: +94 11 2650805
Web: www.techcert.lk
=====HELPING YOU SECURE YOUR INFORMATION ASSETS=====
12 years, 6 months
Problems with Luna PCI HSM and dogtag 1.3
by Riccardo Brunetti
Dear pki-users.
We are setting up a CA subsystem using dogtag 1.3 on CentOS-5.8 and a
HSM Luna PCI3000 (SafeNet).
The HSM card seems to be correctly installed in the system and, using
the command line utilities, we could create a partition on the HSM to
store the crypto data.
Unfortunately, when I run pkicreate and then the configuration wizard in
order to configure the CA subsystem, the HSM modules seems not to be
detected and the system still uses the software "NSS Internal PKCS #11
Module".
I also tried to manually load the pkcs#11 module using the command:
# modutil -dbdir /var/lib/igi-ca/alias -nocertdb -add lunapci -libfile
/usr/lunapci/lib/libCryptoki2_64.so
and the output of the list command is the following:
# modutil -dbdir /var/lib/igi-ca/alias -list
Listing of PKCS #11 Modules
-----------------------------------------------------------
1. NSS Internal PKCS #11 Module
slots: 2 slots attached
status: loaded
slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
2. lunapci
library name: /usr/lunapci/lib/libCryptoki2_64.so
slots: 1 slot attached
status: loaded
slot: Viper PCI Card
token: turintest
-----------------------------------------------------------
Moreover this is the output of TokenInfo command:
# TokenInfo /var/lib/igi-ca/alias/
Database Path: /var/lib/igi-ca/alias/
Found external module 'NSS Internal PKCS #11 Module'
Found external module 'lunapci'
Found external token 'turintest'
Despite all of that, when the configuration wizard comes to the "Key
Store" page the module is not listed.
I then tried to include it manually in the CS.cfg file:
preop.configModules.module0.commonName=lunapci
preop.configModules.module0.imagePath=../img/clearpixel.gif
preop.configModules.module0.userFriendlyName=lunapci
and in this case it is listed but in Status "Not Found"
How can I solve this issue? Do you have some suggestions?
Thank you very much
R. Brunetti
12 years, 6 months
SCEP: Invalid OID in CertRep signerInfo when using SHA-2
by Nimeh, Jamil
Hello all,
I have come across what looks like a bug in SCEP responses from the CA when using SHA-256 and SHA-512.
The problem appears to be the OID that is given in the digestAlgorithm field of the signerInfo portion of the PKCS#7 signature. For CertRep messages using MD5 and SHA-1 the OID is correct and matches the single OID in the digestAlgorithms list from the SignedData segment. In the case of SHA-256 and SHA-512, it appears that the second to the last octet in the two digests (0x2) is missing. For SHA-256 the OID in the signerInfo is "2.16.840.1.101.3.4.1" (it should be ...3.4.2.1). For SHA-512 the OID given is "2.16.840.1.101.3.4.3"when it should end "...3.4.2.3"
When attempting to verify the digest using NSS'SEC_PKCS7VerifySignature() / SEC_PKCS7VerifyDetachedSignature() it fails, and I believe it also fails with similar calls under OpenSSL. There's a mention of the latter on the Dogtag SCEP/SSCEP page under the heading "SSCEP Error". I believe this error is due to this OID discrepancy.
I've been looking in the Dogtag source and the JSS Javadocs to see where this OID might be coming from. Everything I've looked at where OIDs for SHA-2 algorithms are concerned have the right bytes, so I've been unable to pinpoint where the OID is coming from.
I can provide sample CertRep messages with the odd OIDs in there if desired. A sample signerInfo from a SHA-256 CertRep failure message from dumpasn1 is below:
Currently Running:
Fedora Core 15 updated to the latest as of 5/17/2012
pki-core (and other rpms) 9.0.19-1
nss-* 3.13.4-2
jss-4.2.6.24
nspr-4.9-2
(I've also seen this behavior with pki-core 9.0.17 and its corresponding packages as well)
I did go looking through the mailing lists and bugzilla to see if this issue had been found and didn't see anything. If I did overlook it then please accept my apologies. I'm currently working around the problem by using SHA-1, but I'd really like to be able to use the stronger digest algorithms if possible. If anyone knows how to get that working I'd appreciate it.
Thanks,
Jamil
SAMPLE CertRep Fail signerInfo using SHA-256:
60 623: SET {
64 619: SEQUENCE {
68 1: INTEGER 1
71 72: SEQUENCE {
73 67: SEQUENCE {
75 16: SET {
77 14: SEQUENCE {
79 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
: (X.520 DN component)
84 7: PrintableString 'TESTPKI'
: }
: }
93 15: SET {
95 13: SEQUENCE {
97 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
: (X.520 DN component)
102 6: PrintableString 'pki-ca'
: }
: }
110 30: SET {
112 28: SEQUENCE {
114 3: OBJECT IDENTIFIER commonName (2 5 4 3)
: (X.520 DN component)
119 21: PrintableString 'Certificate Authority'
: }
: }
: }
142 1: INTEGER 1
: }
145 12: SEQUENCE {
147 8: OBJECT IDENTIFIER aes (2 16 840 1 101 3 4 1)
: (NIST Algorithm)
157 0: NULL
: }
159 250: [0] {
162 17: SEQUENCE {
164 10: OBJECT IDENTIFIER messageType (2 16 840 1 113733 1 9 2)
: (Verisign PKCS #7 attribute)
176 3: SET {
178 1: PrintableString '3'
: }
: }
181 17: SEQUENCE {
183 10: OBJECT IDENTIFIER pkiStatus (2 16 840 1 113733 1 9 3)
: (Verisign PKCS #7 attribute)
195 3: SET {
197 1: PrintableString '2'
: }
: }
200 17: SEQUENCE {
202 10: OBJECT IDENTIFIER failInfo (2 16 840 1 113733 1 9 4)
: (Verisign PKCS #7 attribute)
214 3: SET {
216 1: PrintableString '2'
: }
: }
219 24: SEQUENCE {
221 9: OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
: (PKCS #9)
232 11: SET {
234 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: (PKCS #7)
: }
: }
245 32: SEQUENCE {
247 10: OBJECT IDENTIFIER senderNonce (2 16 840 1 113733 1 9 5)
: (Verisign PKCS #7 attribute)
259 18: SET {
261 16: OCTET STRING
: A9 7A AB 92 86 A8 C6 FB A7 AA 59 C8 D8 85 5B 8F
: }
: }
279 32: SEQUENCE {
281 10: OBJECT IDENTIFIER
: recipientNonce (2 16 840 1 113733 1 9 6)
: (Verisign PKCS #7 attribute)
293 18: SET {
295 16: OCTET STRING
: BD 5F 02 CC D5 5A 25 34 84 00 78 E2 6B 54 D3 7A
: }
: }
313 47: SEQUENCE {
315 9: OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
: (PKCS #9)
326 34: SET {
328 32: OCTET STRING
: E3 B0 C4 42 98 FC 1C 14 9A FB F4 C8 99 6F B9 24
: 27 AE 41 E4 64 9B 93 4C A4 95 99 1B 78 52 B8 55
: }
: }
362 48: SEQUENCE {
364 10: OBJECT IDENTIFIER transID (2 16 840 1 113733 1 9 7)
: (Verisign PKCS #7 attribute)
376 34: SET {
378 32: PrintableString '856F90890192FFE9A321C83CB56169AA'
: }
: }
: }
412 13: SEQUENCE {
414 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
: (PKCS #1)
425 0: NULL
: }
427 256: OCTET STRING
: 6C 5E EA E3 6E 5B 5D E9 41 72 20 83 33 48 1B 7D
: 3F 5F 1F A6 C3 D3 5D D5 F3 D3 57 E7 A7 7C 65 D1
: 25 39 C0 A3 13 E2 63 10 79 28 55 2C 35 51 E0 0F
: 63 7B F1 C4 F2 56 E1 63 37 78 01 C1 84 38 44 94
: 46 8F 54 89 E0 FB C1 50 F5 15 9F CA B4 1E A7 68
: C1 DE 96 3C AB 79 33 B8 44 44 F2 A1 0B 03 2A FD
: 06 51 5D A1 C6 71 61 50 67 44 C4 94 01 5F 21 1F
: EE CF 4B 8D 79 7F 89 45 0D 32 37 AC BE B2 21 A5
: [ Another 128 bytes skipped ]
: }
: }
: }
: }
: }
12 years, 7 months
Problem with Subject Alternative Name Extension
by Riccardo Brunetti
Dear pki-users.
I'm trying to setup a pki-ca instance to produce X509 certificates which include a Subject Alternative Name Extension with the following attributes:
Criticality = not critical
Type = RFC822Name
Value = the email of the requestor.
I'm using the Signed CMC-Authenticated User Certificate Enrollment profile and this is the relevant section of my /var/lib/pki-ca/profiles/ca/caFullCMCUserCert.cfg file:
policyset.cmcUserCertSet.8.constraint.class_id=extensionConstraintImpl
policyset.cmcUserCertSet.8.constraint.name=Extension Constraint
policyset.cmcUserCertSet.8.constraint.params.extCritical=false
policyset.cmcUserCertSet.8.constraint.params.extOID=2.5.29.17
policyset.cmcUserCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.cmcUserCertSet.8.default.name=Subject Alternative Name Extension Default
policyset.cmcUserCertSet.8.default.params.subjAltExtGNEnable_0=true
policyset.cmcUserCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.cmcUserCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.cmcUserCertSet.8.default.params.subjAltNameExtCritical=false
policyset.cmcUserCertSet.8.default.params.subjAltNameNumGNs=1
The input certificate request is generated using certutil and CMCEnroll and the command used is the following:
certutil -R -g 2048 -s "<the-subject>" -7 "<the-requestor-email>" -d <a-local-dir> ……
The certificate is generated, but the extension is not populated with the email address and I always get:
Identifier: Subject Alternative Name - 2.5.29.17
Critical: no
Value:
RFC822Name: $request.requestor_email$
These are the installed packages:
pki-java-tools-9.0.18-1.fc15.noarch
pki-selinux-9.0.18-1.fc15.noarch
pki-setup-9.0.18-1.fc15.noarch
pki-ca-9.0.18-1.fc15.noarch
dogtag-pki-common-theme-9.0.10-1.fc15.noarch
pki-symkey-9.0.18-1.fc15.x86_64
pki-native-tools-9.0.18-1.fc15.x86_64
dogtag-pki-ca-theme-9.0.10-1.fc15.noarch
pki-console-9.0.5-1.fc15.noarch
pki-util-9.0.18-1.fc15.noarch
dogtag-pki-console-theme-9.0.10-1.fc15.noarch
pki-common-9.0.18-1.fc15.noarch
Does anybody have some suggestion on how to solve this issue? Any input would be very appreciated.
Best Regards
Riccardo
Riccardo Brunetti
INFN-Torino
Tel: +390116707295
riccardo.brunetti(a)to.infn.it
12 years, 7 months
