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]>> 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]>>> 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]>>>>
> > Date: Oct 6, 2006 11:59 AM
> > Subject: Certification Authority (CA) portlet
> > To: [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto: [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> >
> > 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
> >
> >
>
>
