geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <c1vams...@gmail.com>
Subject Re: Fwd: Certification Authority (CA) portlet
Date Tue, 10 Oct 2006 18:11:42 GMT
That should go as part of Keystore portlet (may be), but not CA portlet.

Vamsi

On 10/10/06, Hernan Cunico <hcunico@gmail.com> wrote:
>
> Thanks for the details Vamsi.
> Not that it will be used a lot (a migration scenario) but do you have any
> plans for exporting a whole keystore (and then choose the type) feature?
>
> Cheers!
> Hernan
>
> Vamsavardhana Reddy wrote:
> > Hernan,
> >
> > In the "Issue New Certificate" function, there is no selection of JKS or
> > p12.  The CA will only be generating a certificate and the certificate
> > is usually provided in a base64 encoded text.  Once the requestor
> > receives this text file, he/she will need to import this certificate
> > into a keystore or browser where ever the private key is stored.
> >
> > Regarding search, search based on more criteria is needed.  I am
> > evolving this as I am going about develpoing the CA.  The simplest
> > search (and only search as of now) is based on serial number as the
> > certificates are now stored as <serial-number>.txt.  To support other
> > criteria (in an efficient way) the certificates may need to be stored
> > differently.
> >
> > N2:  A PKCS10 requests will have the name information and public-key
> > combined into a sequence and signed using the private-key.  This is
> > usually generated by tools like keytool.  Some browsers support a KEYGEN
> > tag which will make the browser generate a keypair, combine the
> > public-key along with a "challenge" phrase, sign the same (known as
> > SignedPublicKeyChallenge) and send it to the server when the form is
> > submitted.  CA should be able to handle both the formats for the
> > requests (and any other commonly used formats, like self-signed
> > certificate).
> >
> > Once the CA is setup, CA will need an interface (I call this "CA Helper
> > App" as of now) using which certificates can be requested and downloaded
> > etc.  I am in the process of developing a sample application.  For a
> > certificate request received, processed and user downloads certificate,
> > a typical workflow would be.
> >
> > Step 1:  A user submits a certificate request by accessing a "Request
> > Certificate" page in the application through the web browser.  What
> > happens at this step is that the browser generates a keypair, and sends
> > tha public key (packaged as a SignedPublicKeyAndChallenge) and name
> > information to the application.  Application saves this information in a
> > "CertificateRequestStore" and provides an request-id to the user.
> >
> > Step 2:  CA accesses all these requests in the "CertificateRequestStore"
> > in a screen in the CA portlet under "List Requests waiting verification"
> > and approves or rejects the requests.  In a real-world scenario, CA will
> > have to verify the details provided by the requestor etc.  Once
> > approved, the request will showup in "List Requests ready to be
> fulfilled".
> >
> > Step 3: CA accesses the requests ready to be fulfilled and processes the
> > request by issuing a certificate.  This certificate is stored in the
> > "Certificate Store" and the fufilled request is removed from the
> > "Certificate Request Store".
> >
> > Step 4: User will visit a "Download Certificate" page in the "CA Helper
> > App", provides the request-id given to him (in Step 1) and downloads
> > his/her certificate.  The "CA Helper App" will upload the ceritificate
> > to the user's web browser with appropriate mime-header.  The browser
> > will store the certificate along with the private key and the
> > certificate is ready for use.
> >
> > I have implemented most of it and am testing the code.  I am still using
> > 1.1.1 code base for development since trunk is unstable and I do not
> > want to be blocked by build failures.  Once I complete the testing I
> > will test the code by integrating it into trunk, create a patch and
> > submit to JIRA.  It will be a couple of days more before the new patch
> > will showup in the JIRA.
> >
> > Thanks,
> > Vamsi
> > On 10/10/06, *Hernan Cunico* <hcunico@gmail.com
> > <mailto:hcunico@gmail.com>> wrote:
> >
> >     Hi Vamsi,
> >     I still have not had the chance to check the patch (GERONIMO-2413)
> >     but I do have a few questions form your first note.
> >
> >     4. can you select JKS or p12 in this step? I'm thinking in client
> >     certificates -> HTTPS with Client Authentication scenario
> >
> >     5. in addition on entering the serial #, any chance to list the
> >     existing certificates in the CertificateStore? maybe CN + Alias
> >
> >     N1. does that mean that the CSR will be provided as a text file (on
> >     a specific location) and the portlet will pick them up and list
> >     them? if so, that would be great and a similar structure should be
> >     in place for already signed certificates.
> >
> >     N2. could you expand?
> >
> >     As for IE, I can't find a nice way to say what I think about IE and
> >     VBScripts. All I can say is that probaly 80% or more ( just a wild
> >     guess ) of the users are using IE. Using another browser to
> >     create/retrieve/export the certificate and then import it into IE
> >     does not look like a healthy workaround. Can we add something else
> >     on the server side to "fill-in-the-blanks" from IE?
> >
> >     Cheers!
> >     Hernan
> >
> >     Vamsavardhana Reddy wrote:
> >      > 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?
> >      >
> >      > Thanks,
> >      > Vamsi
> >      > ---------- Forwarded message ----------
> >      > From: *Vamsavardhana Reddy* < c1vamsi1c@gmail.com
> >     <mailto:c1vamsi1c@gmail.com>
> >      > <mailto:c1vamsi1c@gmail.com <mailto:c1vamsi1c@gmail.com>>>
> >      > Date: Oct 6, 2006 11:59 AM
> >      > Subject: Certification Authority (CA) portlet
> >      > To: dev@geronimo.apache.org <mailto:dev@geronimo.apache.org>
> >     <mailto: dev@geronimo.apache.org <mailto:dev@geronimo.apache.org>>
> >      >
> >      > Hi All,
> >      >
> >      > I have uploaded a minimal version of Certification Authority (CA)
> >      > portlet to the JIRA.  See
> >      > http://issues.apache.org/jira/browse/GERONIMO-2413 .  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 software.
> >      > (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 functions:
> >      > 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?
> >      >
> >      > Thanks,
> >      > Vamsi
> >      >
> >      >
> >
> >
>

Mime
View raw message