Hi Vamsi,
great, I saw the updates to the JIRA and yes, I was having some issues building
from trunk. I'm about to give it a shot again, I think it works now.
Nice work ;-) !
Cheers!
Hernan
Vamsavardhana Reddy wrote:
Hi Hernan,
I have uploaded CA portlet and helper application patch to JIRA. With
what the portlet and the helper application provides, you should be able
to submit a certificate request from web browser that supports KEYGEN
tag (IE doesn't) and install the issued certificate back into the web
browser . I have also provided a patch that can be used with 1.1.x
codebase. Incase you are blocked by build problems on trunk you may try
using this patch on branches\1.1 .
Thanks,
Vamsi
On 10/10/06, *Hernan Cunico* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Absolutely, my bad. I guess I'll have a better idea how it is
integrated once I try the patch.
Cheers!
Hernan
Vamsavardhana Reddy wrote:
> That should go as part of Keystore portlet (may be), but not CA
portlet.
>
> Vamsi
>
> On 10/10/06, *Hernan Cunico* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> 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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>> 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* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>
> > > <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>>>
> > > 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>> <mailto:dev@geronimo.apache.org
<mailto:dev@geronimo.apache.org>
> <mailto:dev@geronimo.apache.org
<mailto:dev@geronimo.apache.org>>>
> > <mailto: dev@geronimo.apache.org
<mailto:dev@geronimo.apache.org>
> <mailto:dev@geronimo.apache.org
<mailto:dev@geronimo.apache.org>> <mailto: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
> > >
> > >
> >
> >
>
>
