geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <>
Subject Fwd: Certification Authority (CA) portlet
Date Tue, 10 Oct 2006 06:50:40 GMT
Hi All,

I have not seen any replies to my last post :(

I have identified a few more function required.  These are for the work-flow
a CA might want to follow:
  1. List Requests:  There should be two pages instead of one.
        A)  Listing of requests that are received and need to be verified
(once verified, the request will reach a second list)
        B)  Listing of requests that are verified and ready to be fulfilled.
  2. Logging:  CA should have a separate log of requests received, verified,
fulfilled, certificates revoked etc.

Comments?  Suggestions?  Pointers?

---------- Forwarded message ----------
From: Vamsavardhana Reddy <>
Date: Oct 6, 2006 11:59 AM
Subject: Certification Authority (CA) portlet

Hi All,

I have uploaded a minimal version of Certification Authority (CA) portlet to
the JIRA.  See .  The
JIRA also has some screenshots.  I do not know if anyone has got a chance to
try out the portlet.  Here is an overview of this portlet's functions.

1.  Setup Certification Authority:  The "CA home" page checks if the CA has
already been initialized.  If not, it will provide access to only this
function viz. " Setup Certification Authority".  This function enables the
user to provide details of CA's identity, algorithm parameters for CA's
keypair & signature algorithm, a serial number for CA's self-signed
certificate, validity period for CA's keypair and a password to protect CA's
privatekey.  Once the details are submitted, a keypair and self-signed
certificate are generated and stored in "ca-keystore".  CA portlet uses
KeyStoreGBean to manage its own keypair and certificate.

2. Lock and Unlock CA:  Once the CA is setup, upon a fresh login to Geronimo
Console, users will notice that the CA is in locked state.  "Unlock CA"
function lets the user unlock the CA by providing CA's privatekey password
(provided at the time of CA setup).  Once unlocked, the user will have
access to the CA functions.  "Lock CA" function locks the CA.

3. View CA Details:  This function enables the user to see the details of
CA' certificate and the highest serial number used to by the CA.  Base 64
encoded certificate text on this screen can be copy+pasted into a text file
and sent to the requestor to designate this CA as trusted CA in their
(Note: CA stores the serial number used at the time of setup and increments
it each time a certificate is to be issued.)

4. Issue New Certificate:  This functions lets the CA issue a new
certificate by processing the Certificate Signing Request (CSR)  text.  Upon
pasting the CSR text into a textarea and submitting, a screen will show the
requestor name and public key details from the CSR and lets the user enter
validity period and select the signature algorithm.  The next screen will
show all details and ask for confirmation.  Once confirmed, a certificate is
issued and stored in a "CertificateStore".  The screen will show the details
of the certificate issued.  Base 64 encoded certificate text on this screen
can be copy+pasted into a text file and sent back to the requestor.

5. View Issued Certificate: This function lets the user view a previously
issued certificate by providing the certificate serial number.

More work on the way:
After posting the patch to JIRA, I have found the necessity for a few other
N1.  List Requests:  This function will list all the certificate requests
that are waiting to be fulfilled and provide a link on each request-id so
that the user can click on the links (instead of entering the csr text in a
textarea) and proceed directly to entering certificate validity details etc.
N2.  Process a certificate request based on (Name Attributes +
SignedPublicKeyAndChallenge):  Users requesting a certificate through web
browsers may not be able to submit a PKCS10 Certificate Request.  Netscape,
Firefox (and other browsers??) support a KEYGEN form tag that will let the
browser, upon form submission, generate a key pair, combine the PublicKey &
a Challenge string and sign (this is the SignedPublicKeyAndChallenge),
encode this information in base64 and send it along with other form fields.
In this case, name attributes are not part of a "signed" request and need to
be collected separately.
N3. CA helper application:  This application will be the interface for users
using their web browsers to request a certificate from the CA.  This
application will have
  a) A page with KEYGEN tag to receive SignedPublicKeyAndChallenge along
with name attribute values from the requestor.
  b) A link using which the users can download and install CA's certificate
into their browsers as a trusted certificate.
  c) A page from which the users can download and install the certificate
issued to them by the CA.
This application can store the requests so that the CA portlet can pickup
these and show in "List Requests" page.

To be explored:
How to do this KEYGEN equivalent through Internet Explorer?  I know that it
requires some VBScript to generate a (PKCS10?) certificate request through
Internet Explorer.  I have done this way back in 1998 and don't remember any
details now :o(
A work around would be to make the users use a browser supporting KEYGEN tag
to request and download their certificate.  The certificate and privatekey
can then be exported and imported into IE.  (I don't like this work around.
Or should this be the only option we provide??)

For later:
CRLs etc.

Any suggestions, comments?  Anything I am missing?  Am I heading in the
correct direction?


View raw message