12:48 p.m.
Hi!
I've set up pki-ca, pki-ocsp, pki-ra and pki-kra.
However, it seems that pki-kra doesn't archive any keys.
I've tested it with the following profiles when issuing certificates:
Using the CA instance:
* caUserCert (Manual User Dual-Use Certificate Enrollment) - I know, it
won't work, it's Dual-Use, not Dual-Key. However, the protocol used is CRMF.
* caDirUserCert (Directory-Authenticated User Dual-Use Certificate
Enrollment) - another Dual-Use, not Dual-Key. But CRMF-based.
* caDualRAuserCert (RA Agent-Authenticated User Certificate Enrollment)
- they don't write what "Dual" means here. Is it Dual-Use too?
Using the RA instance:
* caDualRAuserCert (RA Agent-Authenticated User Certificate Enrollment)
- it has "Dual" in its name...
So it seems that there's potential confusion over which "Dual" is
implied in the profile names (does it correspond to key usage, or the
amount of keys?).
Based on my experiments, either all those profiles are single key, or my
client doesn't support dual key generation (it's Firefox 3 nightly build).
So the question is - what combination of certificate profiles and client
(web browser) versions allows for generating dual key certificates whose
keys will be correctly archived by KRA/DRM?
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
--
Aleksander Adamowski
Administrator systemów korporacyjnych; Instruktor
Altkom Akademia S.A. http://www.altkom.pl
Warszawa, ul. Chłodna 51
tel. brak
kom. +48 601-318-080
Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru
Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy
Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa
firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych
celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne
skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A.
company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete
all copies of this message.
1:46 p.m.
There could be multiple issues.
First thing you want to check is whether your ca is configured correctly
with connection to KRA. To check this, look into your CS.cfg file in
<CA install dir>/conf/CS.cfg, and look for
CA.connector.KRA.enable=true
If it's not there, or is false, then you probably did not set it up
correctly. There are several other parameters there that were supposed
to be added automatically during installation, if you had picked the
right options. If you missed, you can reinstall again.
If your KRA is set up correctly, then test it out with caDualCert.cfg,
which will generate a signing cert and an encryption cert for you. The
encryption cert is the one whose private key will be archived.
hope this helps,
Christina
Aleksander Adamowski wrote:
Hi!
I've set up pki-ca, pki-ocsp, pki-ra and pki-kra.
However, it seems that pki-kra doesn't archive any keys.
I've tested it with the following profiles when issuing certificates:
Using the CA instance:
* caUserCert (Manual User Dual-Use Certificate Enrollment) - I know,
it won't work, it's Dual-Use, not Dual-Key. However, the protocol used
is CRMF.
* caDirUserCert (Directory-Authenticated User Dual-Use Certificate
Enrollment) - another Dual-Use, not Dual-Key. But CRMF-based.
* caDualRAuserCert (RA Agent-Authenticated User Certificate
Enrollment) - they don't write what "Dual" means here. Is it Dual-Use
too?
Using the RA instance:
* caDualRAuserCert (RA Agent-Authenticated User Certificate
Enrollment) - it has "Dual" in its name...
So it seems that there's potential confusion over which "Dual" is
implied in the profile names (does it correspond to key usage, or the
amount of keys?).
Based on my experiments, either all those profiles are single key, or
my client doesn't support dual key generation (it's Firefox 3 nightly
build).
So the question is - what combination of certificate profiles and
client (web browser) versions allows for generating dual key
certificates whose keys will be correctly archived by KRA/DRM?
5:08 a.m.
Christina Fu wrote:
There could be multiple issues.
First thing you want to check is whether your ca is configured
correctly with connection to KRA. To check this, look into your
CS.cfg file in <CA install dir>/conf/CS.cfg, and look for
CA.connector.KRA.enable=true
I've already checked that, it's there. Also,
in pkiconsole for the CA
instance, I can see "Data Recovery Manager Connector" in "Certificate
Manager" -> "Connectors".
When I click "Edit", and check its configuration, it corresponds to the
configuration of the pki-kra instance (port number etc.).
If your KRA is set up correctly, then test it out with caDualCert.cfg,
which will generate a signing cert and an encryption cert for you.
The encryption cert is the one whose private key will be archived.
OK, this is what
I was looking for!
When I use the caDualCert profile, the browser asks me for
confirmation/permisson for the CA to make a backup of my encryption
private key - here's a screenshot of how it looks like:
https://olo.org.pl/files/pki/encryption_key_copy.png
Then I can see that _two_ key generation progress dialogs are displayed
consecutively. So two keys and CSRs are indeed generated, and two
certificate requests are added to the CA's request queue.
The remaining question I have is - can I customise the LDAP-based
enrollment profile (caDirUserCert) to generate dual keys just like
caDualCert does?
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
12:09 p.m.
Aleksander Adamowski wrote:
Christina Fu wrote:
> There could be multiple issues.
>
> First thing you want to check is whether your ca is configured
> correctly with connection to KRA. To check this, look into your
> CS.cfg file in <CA install dir>/conf/CS.cfg, and look for
> CA.connector.KRA.enable=true
I've already checked that, it's there. Also, in pkiconsole for the CA
instance, I can see "Data Recovery Manager Connector" in "Certificate
Manager" -> "Connectors".
When I click "Edit", and check its configuration, it corresponds to
the configuration of the pki-kra instance (port number etc.).
>
> If your KRA is set up correctly, then test it out with
> caDualCert.cfg, which will generate a signing cert and an encryption
> cert for you. The encryption cert is the one whose private key will
> be archived.
OK, this is what I was looking for!
When I use the caDualCert profile, the browser asks me for
confirmation/permisson for the CA to make a backup of my encryption
private key - here's a screenshot of how it looks like:
https://olo.org.pl/files/pki/encryption_key_copy.png
Then I can see that _two_ key generation progress dialogs are
displayed consecutively. So two keys and CSRs are indeed generated,
and two certificate requests are added to the CA's request queue.
That's correct.
The remaining question I have is - can I customise the LDAP-based
enrollment profile (caDirUserCert) to generate dual keys just like
caDualCert does?
Yes, all the pages are customizable, with templates, see for example:
/var/lib/pki-<ca-instance-name>/webapps/ca/ee/ca/
and
DirUserEnroll.html
Also:
http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Gu...
M.
8:54 a.m.
Marc Sauton wrote:
> The remaining question I have is - can I customise the LDAP-based
> enrollment profile (caDirUserCert) to generate dual keys just like
> caDualCert does?
>
Yes, all the pages are customizable, with templates, see for example:
/var/lib/pki-<ca-instance-name>/webapps/ca/ee/ca/
and
DirUserEnroll.html
Also:
http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Gu...
M.
Thanks for the hint!
However, it wasn't what I were looking for. Note that I wanted to
customise the enrollment *profile*, not *page*.
I had a look at DirUserEnroll.html and decided that customising it won't
probably allow me to implement directory-populated dual certs since they
require a new profile on the CA server and the page is static, so it's
executed purely on the client. Even if my browser did submit dual
certificate request, it wouldnt have a corresponding profile on the server.
Also, analysing a spaghetti of VBScript and old Netscape-specific JS
didn't seem inspiring.
Instead, I've figured out that it's sufficient to modify certificate
profiles (placed /var/lib/pki-<ca-instance-name>/profiles/ca/) and
register the changes in /etc/pki-<ca-instance-name>/CS.cfg.
So I've made a copy caDualCert.cfg named caDualDirUserCert.cfg and made
some changes inspired by caDirUserCert.cfg. In other words, I did a
semantic merge of caDualCert.cfg and caDirUserCert.cfg.
Here's the unified diff describing the changes (may get messed up by my
automatic line wrap, so I'm also sending it as an attachment):
--- caDualCert.cfg 2008-05-09 14:40:09.000000000 +0200
+++ caDualDirUserCert.cfg 2008-05-22 14:12:47.000000000 +0200
@@ -1,13 +1,11 @@
-desc=This certificate profile is for enrolling dual user certificates.
It works only with Netscape 7.0 or later.
+desc=This certificate profile is for enrolling dual user certificates
(encryption/signing certificate pairs) with directory-based authentication.
visible=true
enable=true
enableBy=admin
-name=Manual User Signing & Encryption Certificates Enrollment
-auth.class_id=
-input.list=i1,i2,i3
+name=Directory-Authenticated User Dual-key Certificate Enrollment
+auth.instance_id=UserDirEnrollment
+input.list=i1
input.i1.class_id=dualKeyGenInputImpl
-input.i2.class_id=subjectNameInputImpl
-input.i3.class_id=submitterInfoInputImpl
output.list=o1
output.o1.class_id=certOutputImpl
policyset.list=encryptionCertSet,signingCertSet
@@ -16,7 +14,7 @@
policyset.encryptionCertSet.1.constraint.name=Subject Name Constraint
policyset.encryptionCertSet.1.constraint.params.pattern=UID=.*
policyset.encryptionCertSet.1.constraint.params.accept=true
-policyset.encryptionCertSet.1.default.class_id=userSubjectNameDefaultImpl
+policyset.encryptionCertSet.1.default.class_id=authTokenSubjectNameDefaultImpl
policyset.encryptionCertSet.1.default.name=Subject Name Default
policyset.encryptionCertSet.1.default.params.name=
policyset.encryptionCertSet.2.constraint.class_id=validityConstraintImpl
@@ -85,7 +83,7 @@
policyset.encryptionCertSet.8.default.name=Subject Alt Name Constraint
policyset.encryptionCertSet.8.default.params.subjAltNameExtCritical=false
policyset.encryptionCertSet.8.default.params.subjAltExtType_0=RFC822Name
-policyset.encryptionCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
+policyset.encryptionCertSet.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$
policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_0=true
policyset.encryptionCertSet.8.default.params.subjAltNameNumGNs=1
policyset.encryptionCertSet.9.constraint.class_id=signingAlgConstraintImpl
@@ -99,7 +97,7 @@
policyset.signingCertSet.1.constraint.name=Subject Name Constraint
policyset.signingCertSet.1.constraint.params.pattern=UID=.*
policyset.signingCertSet.1.constraint.params.accept=true
-policyset.signingCertSet.1.default.class_id=userSubjectNameDefaultImpl
+policyset.signingCertSet.1.default.class_id=authTokenSubjectNameDefaultImpl
policyset.signingCertSet.1.default.name=Subject Name Default
policyset.signingCertSet.1.default.params.name=
policyset.signingCertSet.2.constraint.class_id=validityConstraintImpl
@@ -158,7 +156,7 @@
policyset.signingCertSet.8.default.name=Subject Alt Name Constraint
policyset.signingCertSet.8.default.params.subjAltNameExtCritical=false
policyset.signingCertSet.8.default.params.subjAltExtType_0=RFC822Name
-policyset.signingCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
+policyset.signingCertSet.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$
policyset.signingCertSet.8.default.params.subjAltExtGNEnable_0=true
policyset.signingCertSet.8.default.params.subjAltNameNumGNs=1
policyset.signingCertSet.9.constraint.class_id=signingAlgConstraintImpl
Registering a new profile requires corresponding changes in CS.cfg:
Index: CS.cfg
===================================================================
--- CS.cfg (revision 983)
+++ CS.cfg (revision 985)
@@ -781,7 +781,7 @@
oidmap.subject_info_access.class=netscape.security.extensions.SubjectInfoAccessExtension
oidmap.subject_info_access.oid=1.3.6.1.5.5.7.1.11
os.userid=nobody
-profile.list=caUserCert,caDualCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caOtherCert,caCACert,caInstallCACert,caRACert,caOCSPCert,caTransportCert,caDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthDRMstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,DomainController,caDualRAuserCert,caRAagentCert,caRAserverCert
+profile.list=caDualDirUserCert
profile.DomainController.class_id=caEnrollImpl
profile.DomainController.config=/var/lib/pki-ca/profiles/ca/DomainController.cfg
profile.caAdminCert.class_id=caEnrollImpl
@@ -852,6 +852,8 @@
profile.caTransportCert.config=/var/lib/pki-ca/profiles/ca/caTransportCert.cfg
profile.caUserCert.class_id=caEnrollImpl
profile.caUserCert.config=/var/lib/pki-ca/profiles/ca/caUserCert.cfg
+profile.caDualDirUserCert.class_id=caEnrollImpl
+profile.caDualDirUserCert.config=/var/lib/pki-ca/profiles/ca/caDualDirUserCert.cfg
registry.file=/var/lib/pki-ca/conf/registry.cfg
request.assignee.enable=true
securitydomain.flushinterval=86400000
Note that additionally I've removed all the other profiles from the list
and left only my profile as active (profile.list=caDualDirUserCert). You
may not want to do this in your case.
After restarting pki-ca instance, I can visit
https://CA_SERVER:9443/ca/ee/ca/profileList and I can see only my new
profile.
Then I can visit
https://CA_SERVER:9443/ca/ee/ca/profileSelect?profileId=caDualDirUserCert
and, as expected, I have a LDAP directory-based authentication form and
the generated certificate will be dual:
===============
Authentication - LDAP UID & Password Authentication
This plugin authenticates the username and password provided by the user
against an LDAP directory. It works with the Dir-Based Enrollment HTML form.
# LDAP User ID [ ]
# LDAP User Password [ ]
Inputs
Dual Key Generation
# Key Generation Request Type
crmf
# Key Generation Request
1024 (Encryption), 1024 (Signing)
===============
This is exactly what I were trying to accomplish.
BTW, this procedure deserves a detailed documentation on
http://www.redhat.com/docs/manuals/cert-system/.
I've also found a problem with generating subject names from LDAP, but
this is a different, unrelated story, so I'll post it as a new thread.
Thanks for your suggestions!
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
5812
days inactive
5819
days old
4 comments
4 participants
participants (4)
-
Aleksander Adamowski -
Aleksander Adamowski -
Christina Fu -
Marc Sauton