jonah instructions.htm

IBM提供的CA认证系统

<tr>
<td ALIGN=CENTER COLSPAN="2">The RA is now up and running and waiting for
requests!</td>
</tr>
</table>

<li>
So now it is time for enrollment! What is enrollment? Jonah is set up so
the CA does not talk directly to End Entities. All communications to the
outside world are done through the RA. That way the CA can be an ultra
secure machine not sitting on a public network, and the only thing it has
to know how to talk to is the RA. In order for this to work the RA needs
to enroll with the CA so they know how to talk to each other, and so they
can exchange public keys so communications can be secure. The next process
is enrollment and it is initiated from the RA.</li>

<table BORDER >
<tr>
<td>On the RA, Select Actions->Enroll with CA</td>

<td ALIGN=CENTER><img src="images/en01.jpg" height=223 width=324></td>
</tr>

<tr>
<td>Currently getting CA information out of LDAP is not implemented so
you need get the CA information file that was created during the CA bootstrap
procedure to the RA. This file contains no sensitive information so the
file does not need to be transported in a protected way.</td>

<td ALIGN=CENTER><img src="images/en02.jpg" height=334 width=307></td>
</tr>

<tr>
<td>Select file and specify the path name for the CA information file in
the Filename text area (or use the <b>Browse</b>) button.</td>

<td ALIGN=CENTER><img src="images/en03.jpg" height=334 width=307></td>
</tr>

<tr>
<td>You must now get the CA's certificate fingerprint from the CA. This
is an out of band step that makes sure that the certificate you got is
really from the CA you want to enroll with.</td>

<td ALIGN=CENTER><img src="images/en03a.jpg" height=334 width=307></td>
</tr>

<tr>
<td>To get the CA's fingerprint you must go to the CA GUI and select Actions->Display
Fingerprint.</td>

<td ALIGN=CENTER><img src="images/en04.jpg" height=244 width=370></td>
</tr>

<tr>
<td>The value of the Fingerprint field is what must be transmitted to the
RA. This can be done via cut and paste if the are on the same machine or
manually typed into the RA.</td>

<td ALIGN=CENTER><img src="images/en05.jpg" height=202 width=433></td>
</tr>

<tr>
<td>Back on the RA the fingerprint needs to be entered. Click on <b>Next</b>.
When you click on next the fingerprint that got entered is compared to
the fingerprint of the cert in the CA info file to make sure they match.</td>

<td ALIGN=CENTER><img src="images/en06.jpg" height=334 width=307></td>
</tr>

<tr>
<td>Select the certificate that you would like to use to enroll with. There
should only be one certificate in the selection box with a serial number
of 0. This should be the certificate you use to enroll with. This is the
self signed certificate that got created during the RA bootstrap process.
Click on <b>finish</b> when done.</td>

<td ALIGN=CENTER><img src="images/en07.jpg" height=334 width=307></td>
</tr>

<tr>
<td>There should now be an entry under the Certificates tab on the RA with
the a status of <i>EnrollWaiting for CA</i>. This means the request has
been sent to the CA and now you are waiting for a response from the CA.</td>

<td ALIGN=CENTER><img src="images/en08.jpg" height=240 width=234></td>
</tr>

<tr>
<td>On the CA Select the <i>EnrollActive</i> entry. This is the enrollment
request from the RA.</td>

<td ALIGN=CENTER><img src="images/en09.jpg" height=192 width=258></td>
</tr>

<tr>
<td>On the right hand side of the screen you can modify any of the fields
in the certificate request such as start and end date or name. If you do
not modify any of these fields they well get filled in with default values
when the certificate is created. Click on <b>Approve</b> when done.</td>

<td ALIGN=CENTER><img src="images/en10.jpg" height=333 width=332></td>
</tr>

<tr>
<td>The CA now needs to get from the RA the URL that the RA accepts connections
on, and the fingerprint of the certificate that the RA used to enroll with.
The URL is in the form of <tt>pkix://hostname:port</tt> where hostname
is the hostname that the RA is running on (you can use localhost if they
are on the same machine) and the port number is the same port number that
was specified in the transports section of the RA setup procedure (and
it can be found in the JonahRA.ini file in the <tt>[Transports]</tt> section
with the name of <tt>TCPPort</tt>). The fingerprint from the RA is obtained
the same way as it was from the CA: The Actions->Display Fingerprint menu
item on the RA. Click on <b>OK</b> when done.</td>

<td ALIGN=CENTER><img src="images/en11.jpg" height=202 width=433></td>
</tr>

<tr>
<td>The status in the Certificate view on the CA will change and eventually
it will vanish</td>

<td ALIGN=CENTER><img src="images/en12.jpg" height=203 width=236></td>
</tr>

<tr>
<td>On the RA the status in the certificate view will change to <i>EnrollCA
Approved</i> this means that the RA is now successfully enrolled with the
CA</td>

<td ALIGN=CENTER><img src="images/en13.jpg" height=102 width=244></td>
</tr>

<tr>
<td ALIGN=CENTER COLSPAN="2">The CA and RA are now enrolled!</td>
</tr>
</table>

<li>
Now that the CA and RA are up, running and know about each other it is
time to bring in the final player, The End Entity (EE). The EE is the person
who requests certificates, uses them, and can revoke them. Our EE code
is a simple GUI that basically deals with requesting and revoking certificates.
Using them is an exercise left up to the reader. Start the EE by changing
directory to <strong>$PKIXDIR</strong> running <tt>JonahEE.bat</tt> on windows or <tt>run_ee</tt>
on solaris.</li>

<table BORDER >
<tr>
<td>The first step in the EE requesting a certificate happens at the RA.
The RA pre-registers the user. This creates a new transaction at the RA
that is well become the certificate request. To pre-register a user go
to the RA GUI and select Actions->preregister user.</td>

<td ALIGN=CENTER><img src="images/pr01.jpg" height=204 width=254></td>
</tr>

<tr>
<td>The dialog that comes up is used to put some information into the a
preregistration record that well be given to the EE so it has enough information
to generate a cert request. The information that can be supplied on this
screen is a selection of CAs that this RA talks to, a name for the EE,
and a password to protect the pre-registration record with. There is also
an "authenticate user" check box on this screen. This is used for the RA
to indicate if the end entity has proven who they are yet. For example
a person goes to the RA and says they want a certificate and they show
the RA their passport with their name in it. The RA should fill in the
name field and check the authenticate user button. In the text area by
the check box the RA can indicate how the user authenticated themselves.
<p>The pre-registration record will also contain a transaction identifier
and URL so the EE knows how to communicate with the RA. The pre-registration
record gets written out to a file. This file needs to be transmitted to
the EE. The password also needs to be transmitted to the EE, but the password
needs to be sent in a secure out-of-band way.</td>

<td ALIGN=CENTER><img src="images/pr02.jpg" height=334 width=351></td>
</tr>

<tr>
<td>The EE is now ready to generate a certificate request. On the EE select
Actions->Create Certificate Request.</td>

<td ALIGN=CENTER><img src="images/cr01.jpg" height=186 width=306></td>
</tr>

<tr>
<td>Enter the pathname for the preregistration record you got from the
RA, and enter the password you got with the preregistration record.</td>

<td ALIGN=CENTER><img src="images/cr02.jpg" height=227 width=408></td>
</tr>

<tr>
<td>You can now specify what you would want in this certificate. (name,
start date, end date etc). Except for a key, whatever you do not supply
well be specified by the RA/CA. But you do need to supply a public key
so click on the <b>Key</b> tab on the right hand side of the screen. Select
EE generated key, and the desired key type and length. EE generated keys
are the only types of keys supported at this time.</td>

<td ALIGN=CENTER><img src="images/cr03.jpg" height=325 width=315></td>
</tr>

<tr>
<td>After you specified everything you want to hit the
<b>submit</b>
button at the bottom of the screen. Check the export to smart card option
and enter the User PIN you used when initializing the EE's virtual smart
card (when you ran initsc with no arguments). When done click on <b>Export</b>.
This is going to generate a keypair, store it on the smart card and send
the request to the RA. So it might take a little bit of time.</td>

<td ALIGN=CENTER><img src="images/cr05.jpg" height=281 width=286></td>
</tr>

<tr>
<td>The Cert Request has left the EE and is now at the RA.</td>

<td ALIGN=CENTER><img src="images/cr06.jpg" height=177 width=251></td>
</tr>

<tr>
<td>The certificate request is now active on the RA, Go to the RA GUI and
you should see a <b>CertActive</b> entry in the left pane.</td>

<td ALIGN=CENTER><img src="images/cr07.jpg" height=220 width=237></td>
</tr>

<tr>
<td>The RA now has the ability to change any of the fields in the cert
request.  Or it can <b>Approve</b> it in which case it'll be sent to
the CA, or it can <b>Reject</b> reject it in which case it'll send a
rejection message back to the EE. For this exercise we are going to
approve it. Before we approve the request make sure the authenticate
user button is checked.  It is the RA's responsibility to make sure
that the requester of the certificate is who they say they are, so at
some point in time the RA does have to authenticate the user. Click on
<b>Approve</b>.</td>

<td ALIGN=CENTER><img src="images/cr08.jpg" height=332 width=271></td>
</tr>

<tr>
<td>Go to the CA GUI, on the left hand side you'll see a request in the 
<b>CertActive</b> state. Select this request, and the right hand side of 
the screen will update with the properties of this request. Like the RA, 
the CA has two options here, it can approve the request, in which case 
it'll create a certificate to be sent back to the EE, or it can deny the 
request in which case an error message well be sent back to the EE. The 
CA can also change any of the fields in the certificate request. Click 
on <b>Approve</b> to create the certificate.</td>

<td ALIGN=CENTER><img src="images/cr09.jpg" height=194 width=256></td>
</tr>

<tr>
<td>The request now makes it way back to the end entity. First
the CA ...</td>

<td ALIGN=CENTER><img src="images/cr10.jpg" height=202 width=259></td>
</tr>

<tr>
<td>Then the RA&nbsp;</td>

<td ALIGN=CENTER><img src="images/cr11.jpg" height=199 width=264></td>
</tr>

<tr>
<td>And finally to the EE</td>

<td ALIGN=CENTER><img src="images/cr12.jpg" height=181 width=260></td>
</tr>

<tr>
<td>We are almost done! Now that the EE has the final cert back it can
review it to make sure it is what they wanted <i>(OK, there is a bug in
the EE GUI that prevents it from displaying the contents of the certificate
on the right hand side. So you really can't look at the certificate, but
lets pretend.)</i>. If the certificate is what you want you should press
the <b>Confirm</b> button. This sends a message to RA telling it that the
cert is OK, and that it can go ahead and publish it to LDAP.</td>

<td ALIGN=CENTER><img src="images/cr13.jpg" height=100 width=317></td>
</tr>

<tr>
<td>If you look on the RA the request vanished from the certificates section
on the right hand side, if you click on the postings tab you well see the
queue for things to be posted to LDAP, once they get posted to LDAP the
will disappear from this tab.</td>

<td ALIGN=CENTER><img src="images/cr14.jpg" height=194 width=232></td>
</tr>

<tr>
<td COLSPAN="2">If the certificate is not what you wanted, or after you
confirm it you decide you do not want the certificate anymore, you can
hit the <b>Revoke</b> button. This will create a revocation request. The
process for submitting a revocation request is similar to that of the cert
request.</td>
</tr>
</table>
</ol>
</ol>

</body>
</html>