Hi List-
I'm finding myself getting confused about which OpenCA web form fields
are associated with which certificate fields as I request a certificate
using OpenCA.
For example, I just finished requesting a new certificate using the
Basic Certificate Request web form (/pub-->User-->Request a
Certificate-->Basic Certificate Request). Then I approved it, moved it
up to the CA, issued the cert, moved it back down to the RA, then picked
up the new cert and examined the web form fields in the request and
compared them to the cert fields.
Here's what I saw:
When requesting pki-last.crt, the following fields were as follows:
==============(initial web form with empty fields)=====
Basic Certificate Request
Please enter your data in the following form.
Certificate Data
E-Mail
Name
Certificate Request Group
alternative email
IP address
DNS name
DNS name
User Data
Name (first and Last name)
Email
Department
Telephone
Level Of Assurance chose the LOA you would like to be authenticated
against.
Role
Registration Authority chose the RA where you will be authenticated.
PIN [used to verify the certification request, min 10 chars (please
write
it down for later usage)]
Re-type your PIN for confirmation
Choose a keysize
==========form filled out and submitted gives================
Confirm Certificate Request
Following are listed data received. Please check carefully information
here
reported with the ones in your possession.
Certificate Data
E-Mail [EMAIL PROTECTED]
Name Two Two
Certificate Request Group Partners
alternative email [EMAIL PROTECTED]
IP address 001.002.003.004
DNS name five.five.com
DNS name six.six.com
User Data
Name (first and Last name) Seven Seven
Email [EMAIL PROTECTED]
Department Nine
Telephone 101.101-1010
Level Of Assurance (LOA) basic
Role Mail Server
Registration Authority Help Desk 1
Keysize 1024
============finalizing request, I get==========
Thank you for requesting your certificate from our organization, your
request with the serial 3360 it's been successfully archived and it is
now
waiting for approval by any of our Registration Authorities (if you are
unsure about the receiving of your request by this server, you can check
the list of new requests).
To complete the certification process you have to go to one of our
Registration Authority office with one of the following documents: o ID
card or passport. o Documnetation asserting your role and authorization
for
requesting a certificate for your organization. If you still have doubts
about the issuing process, just use the links provided in the
Information
section to learn how to complete all the needed steps.
ADDITIONAL_ATTRIBUTE_DEPARTMENT Nine
ADDITIONAL_ATTRIBUTE_EMAIL [EMAIL PROTECTED]
ADDITIONAL_ATTRIBUTE_REQUESTERCN Seven Seven
ADDITIONAL_ATTRIBUTE_TELEPHONE 101.101-1010
LOA 30
NOTBEFORE Thu Sep 30 17:38:43 2004 UTC
PIN ef5ceda7b90da75595bb5ec156084140a39d80ef
RA Help Desk 1
ROLE Mail Server
SERIAL 3360
SUBJECT_ALT_NAME email: [EMAIL PROTECTED],IP: 001.002.003.004,DNS:
five.five.com,DNS: six.six.com
TYPE PKCS#10
==============================================
And the certificate itself looks like this:
==============================================
bash-2.05b$ openssl x509 -noout -text -in pki-last.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 10 (0xa)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=Folkvang Certification Services,
OU=Certification Services, CN=Kevin Ford/[EMAIL PROTECTED]
Validity
Not Before: Sep 30 17:48:17 2004 GMT
Not After : Sep 30 17:48:17 2005 GMT
Subject: C=US, O=Folkvang Certification Services, OU=Partners,
CN=Two Two/serialNumber=10
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:9f:72:24:73:5a:a2:64:05:01:dc:ab:14:b9:1c:
7a:1b:e9:35:7d:0b:d5:b9:ed:4f:5c:22:ab:bd:31:
04:6c:c0:f9:78:02:9b:96:fa:c5:01:09:5b:f5:a7:
fd:1b:5a:d2:8e:38:8a:b4:f2:c9:0d:a5:be:23:08:
72:ba:96:f8:39:f5:2c:06:c5:70:9c:a8:4a:f1:8c:
e6:4d:fd:bf:89:62:3f:60:9f:28:c5:57:5d:d8:d1:
24:b5:7d:c6:15:7f:64:fd:b9:6c:59:75:ad:87:16:
23:cc:3c:14:52:d8:da:7a:72:99:68:ad:ec:f3:47:
ac:8b:40:c4:0b:23:0f:18:7d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Certificate Policies:
Policy: 1.2.3.3.4
Policy: 1.2.3.3.5
Policy: 1.2.3.3.6
CPS: http://some.url.org/cps
Netscape Cert Type:
SSL Client, SSL Server
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server
Authentication, Microsoft Server Gated Crypto, Netscape Server Gated
Crypto
Netscape Comment:
Mail-Server of Folkvang Certification Services
X509v3 Subject Key Identifier:
CB:22:D4:27:99:2B:A8:73:7D:95:C8:6C:24:9F:01:2A:36:52:31:44
X509v3 Authority Key Identifier:
keyid:24:FD:3B:29:5E:AB:E8:02:97:94:FB:8D:2B:DC:2D:5C:5B:A8:5B:E5
DirName:/C=US/O=Folkvang Certification
Services/OU=Certification Services/CN=Kevin
Ford/[EMAIL PROTECTED]
serial:00
X509v3 Subject Alternative Name:
email:[EMAIL PROTECTED], IP Address:1.2.3.4,
DNS:five.five.com, DNS:six.six.com, email:[EMAIL PROTECTED]
X509v3 Issuer Alternative Name:
email:[EMAIL PROTECTED]
Netscape CA Revocation Url:
http://ares.folkvang.org/pub/crl/cacrl.crl
Netscape Revocation Url:
http://ares.folkvang.org/pub/crl/cacrl.crl
X509v3 CRL Distribution Points:
URI:http://ares.folkvang.org/pub/crl/cacrl.crl
Signature Algorithm: sha1WithRSAEncryption
40:c6:14:57:30:29:71:58:f9:52:9a:9e:af:b0:ae:08:26:10:
45:23:02:53:2f:06:28:51:af:79:a1:1c:64:f0:2d:4a:55:ff:
71:b8:21:a1:e8:0e:bb:7b:ad:78:71:6d:de:94:e2:36:8b:d6:
c8:ad:fd:20:16:8a:3d:51:17:32:99:19:a7:db:e0:d5:80:59:
bc:30:2b:7a:8d:51:98:62:ee:a8:b3:23:08:34:25:3a:12:50:
d4:8a:8f:d1:01:a9:6a:6c:5c:4f:4a:4a:96:20:17:22:77:96:
88:81:3f:66:bc:74:3f:33:e9:06:03:df:52:f3:87:73:14:6f:
06:b6:d8:26:b5:90:03:1b:f1:5b:91:7b:1d:2d:0b:f3:90:06:
8f:ed:a8:bd:e4:d3:50:2e:c6:73:92:a0:97:9c:53:78:b8:5c:
b0:8f:bc:35:a0:43:60:5b:3c:c2:6a:7c:42:08:97:2c:6f:05:
c2:2f:dd:94:dc:a5:6c:0c:d7:31:d2:31:31:1c:f1:67:33:85:
76:64:d0:3f:63:ed:34:6e:70:97:60:ca:30:09:8e:6b:40:fb:
a1:ff:08:3b:f2:11:3c:00:be:2f:e8:3f:eb:b3:f9:3a:e7:9d:
c3:5c:48:8e:ed:ae:30:7b:eb:20:b5:47:e8:48:9f:f7:9d:5f:
30:fe:9b:07:a3:31:a6:2d:52:a1:66:00:5d:6b:d8:3d:2f:72:
b7:9e:ae:3e:9b:c2:52:99:04:b5:eb:c3:6b:74:ae:37:70:aa:
02:30:07:eb:3b:a3:f0:af:87:cc:d9:4d:bd:04:5a:2b:21:7a:
3c:20:6e:42:56:35:b7:34:7f:85:89:4c:4a:a4:98:65:94:f4:
76:56:73:7f:49:ce:7b:cf:36:da:7c:5b:ae:10:ce:e4:72:98:
fa:7c:07:e7:8f:1b:49:14:de:4a:87:dc:9c:2a:ad:0a:6d:af:
1f:c4:a0:77:1d:d2:35:3f:c0:3a:26:bd:40:38:95:3a:03:d6:
d9:3d:eb:44:3d:2f:1f:51:94:c9:13:a8:73:b0:26:75:6a:6d:
ea:2c:31:3c:a6:cf:34:40:cc:7d:e8:ef:b3:21:d2:64:1e:b6:
db:9b:6d:bc:58:29:c8:7b:03:f5:f0:a4:67:ed:2b:9b:42:24:
9e:c3:d6:7a:fe:d7:ee:4a:8f:c1:b1:59:f7:4c:3a:ba:9e:d2:
94:5c:e1:d2:1b:c6:de:6b:dc:e3:08:6d:87:2b:e3:c6:74:c6:
11:03:f9:b4:9b:00:2e:d8:c6:f0:55:89:f2:a1:68:b4:f7:53:
d9:ff:e6:bf:19:01:6b:5b:ef:b7:12:fd:01:f5:75:fa:d1:82:
47:4f:9c:f9:25:68:69:a4
==============================================
Therefore, we have the following web form fields and their associated
certificate fields:
Basic Certificate Request
Please enter your data in the following form.
Certificate Data
1) E-Mail: X509v3 Subject Alternative Name:
email:[EMAIL PROTECTED], IP Address:1.2.3.4,
DNS:five.five.com, DNS:six.six.com, email:[EMAIL PROTECTED]
Here, the very first web form field is under the heading "Certificate
Data" in the web form and the field name in the web form is "E-Mail"
But it seems odd to me that the contents of this web form show up in the
certificate only as an apparantly tertiary email address (the second
email address in a list of two email addresses in the "Subject
_Alternative_ Name" field).
What would be considered to be a "primary" (vice alternative) email
address for the subject of the certificate (the user)?
2) Name: Certificate Subject CN (this makes sense to me)
3) Certificate Request Group: Certificate Subject OU (makes sense)
4) alternative email: X509v3 Subject Alternative Name:
email:[EMAIL PROTECTED]
Seems odd to me. Why isn't the first email address in the web form
([EMAIL PROTECTED]) showing up first here? And the second email address in
the web form ([EMAIL PROTECTED]) showing up last in Subject Alternative
Name in the cert?
If I use a certificate with S/MIME and an email client, does the client
make a comparison between one of these email addresses (in the cert) and
the email address that the client associates with a particular identity
(configured in the email client---say, checking mail for [EMAIL PROTECTED])?
If so, which one? I ran into some difficulty trying this with Apple's
OSX 10.3 Mail.App (which is S/MIME aware) and one of OpenCA's
certificates.
5) IP Address: X509v3 Subject Alternative Name:
email:[EMAIL PROTECTED], IP Address:1.2.3.4
I guess this makes sense to me. So, is there no dedicated field for an
IP address (thus requiring us to put it in the Subject Alternative Name
cert field)?
And which IP address is supposed to go in this web form field? If I'm
requesting a server certificate, should I put the IP address of the
server computer where I will install the cert? How is that used (or is
it)? Does a client program compare the IP address of the server with
the content of this field and complain if they don't match?
What if I'm requesting a user certificate with no fixed IP address?
6) DNS name: X509v3 Subject Alternative Name:
email:[EMAIL PROTECTED], IP Address:1.2.3.4,
DNS:five.five.com
Same questions as above: no dedicated field for DNS? What DNS
information goes here? If I'm requesting a server certificate, is it
the DNS name (FQDN) of the server? Is the second DNS name field for a
possible nickname for the server? How is this field used? Does a
client program compare the DNS name here with the actual DNS name of the
server bearing the cert and complain if they don't match? I have
noticed this sort of thing going on when the CN field in the cert does
not match the name of the server computer.
I saw
http://www.mail-archive.com/openca-users%40lists.sourceforge.net/msg04397.html in the
mail archives. Are the DNS entries here to permit the functionality mentioned there?
If so, what is matched against what or is that dependent upon the application?
User Data
7) Name (first and Last name): ADDITIONAL_ATTRIBUTE_REQUESTERCN
I see from the confirmation screen in the web interface that this field
is called ADDITIONAL_ATTRIBUTE_REQUESTERCN, but I don't see its contents
anywhere in the certificate. How is this field used by OpenCA?
8) Email: ADDITIONAL_ATTRIBUTE_EMAIL
I see from the confirmation screen in the web interface that this field
is called ADDITIONAL_ATTRIBUTE_EMAIL, but its contents are nowhere in
the certificate. How is this field used by OpenCA? Is the notification
that the certificate is ready to be picked up mailed here?
9) Department: ADDITIONAL_ATTRIBUTE_DEPARTMENT
same questions as for 7 and 8.
10) Telephone: ADDITIONAL_ATTRIBUTE_TELEPHONE
same questions as for 7, 8, and 9.
I did see Michael Bell's reply to a similar question at
http://www.mail-archive.com/openca-users%40lists.sourceforge.net/msg04604.html
but my questions are a little more in-depth than that poster's
question. I can see where the telephone number might be used by the RA
to contact someone in a hurry, and same for department. Is email used
the same way (seems like we have three different email addresses just
for the subject so far)? Are these data stored in the database? If so,
how would I browse the database? Just get a mysql client and browse
through it that way or does OpenCA have a tool for that?
Are these additional attributes only available in the SQL database or
does the LDAP directory also get them?
11) LOA: I see Dalani addressed this issue here
(http://www.mail-archive.com/openca-users%40lists.sourceforge.net/msg04255.html)
It doesn't seem to be a part of the certificate, though. So how is the
owner of the certificate supposed to use it? Or is it matched with the
cert serial number and thus a third party could look up a person's or a
server's cert in the OpenCA pub gateway (database) and see that it has
LOA 30 (or whatever)?
12) Role: How is this used by OpenCA? Is it matched with the cert's
serial number and a third party can look up what the intent of the cert
is for?
13) RA: this is simply for the person requesting the certificate to
choose where they will physically go to authenticate themselves with a
passport or whatever, right? He can go to Help Desk 1 in Office A in
City B or Help Desk 2 in Office C in City D, right?
14) PIN: it looks like anyone can pickup a cert, so how is this used?
Based on my experimentation, it does not seem to be the code used for
revoking the cert... or is it? I generated a browser-auto-detect cert
and it seemed that the code I used to revoke it was randomly chosen by
the browser...
I did search the mail archives for these issues, but I hope you'll
pardon me if I missed an answer in the archives to a question I'm asking
here. I also read the guide, but the explanations given did not give me
a good understanding of what's going on here. Sorry if I'm being
dense...
Are my questions silly because I'm missing something important about the
PKIX/X509 certificate system that I should know about it? I have
O'Reilly's book, _Network Security with OpenSSL_ and it does talk in
pretty good detail about X509, setting up your own CA (even mentions
OpenCA!) but I don't find answers to these questions in that book. I've
glanced at some of the RFCs, but they are so extremely low-level that I
know I'm only grasping about 10-20% of what's there.
What's a good introductory text to get better acquainted with what all
the cert fields are for?
Thanks,
Kevin
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Openca-Users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-users
