You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Vamsavardhana Reddy <c1...@gmail.com> on 2006/10/06 08:29:58 UTC
Certification Authority (CA) portlet
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
[ Show ยป <http://issues.apache.org/jira/browse/GERONIMO-2413> ]
Vamsavardhana Reddy<http://issues.apache.org/jira/secure/ViewProfile.jspa?name=vamsic>
[28/Sep/06 01:51 AM]
GERONIMO-2413<http://issues.apache.org/jira/browse/GERONIMO-2413>.patch:
Certification Authority portlet with the following functions: 1. Setup
Certification Authority: Lets the user input CA details and initialize the
CA. CA's keys are stored and accessed using KeystoreGBean. 2. Lock and
Unlock CA 3. View CA Details: Shows the details of the CA's certificate etc.
3. Issue New Certificate: Processes a CSR and issues a certificate 4. View
Issued Certificate: Previously issued certificates can be viewed by
providing the serial number.
Re: Fwd: Certification Authority (CA) portlet
Posted by Hernan Cunico <hc...@gmail.com>.
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* <hcunico@gmail.com
> <ma...@gmail.com>> 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* <hcunico@gmail.com
> <ma...@gmail.com>
> > <mailto:hcunico@gmail.com <ma...@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
> <ma...@gmail.com>
> > <mailto:hcunico@gmail.com <ma...@gmail.com>>
> > > <mailto: hcunico@gmail.com <ma...@gmail.com>
> <mailto: hcunico@gmail.com <ma...@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
> <ma...@gmail.com>
> > <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>
> > > <mailto:c1vamsi1c@gmail.com
> <ma...@gmail.com> <mailto:c1vamsi1c@gmail.com
> <ma...@gmail.com>>>
> > > > <mailto: c1vamsi1c@gmail.com
> <ma...@gmail.com> <mailto:c1vamsi1c@gmail.com
> <ma...@gmail.com>>
> > <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>
> <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>>>>
> > > > Date: Oct 6, 2006 11:59 AM
> > > > Subject: Certification Authority (CA) portlet
> > > > To: dev@geronimo.apache.org
> <ma...@geronimo.apache.org>
> > <mailto:dev@geronimo.apache.org
> <ma...@geronimo.apache.org>> <mailto:dev@geronimo.apache.org
> <ma...@geronimo.apache.org>
> > <mailto:dev@geronimo.apache.org
> <ma...@geronimo.apache.org>>>
> > > <mailto: dev@geronimo.apache.org
> <ma...@geronimo.apache.org>
> > <mailto:dev@geronimo.apache.org
> <ma...@geronimo.apache.org>> <mailto:dev@geronimo.apache.org
> <ma...@geronimo.apache.org>
> > <mailto:dev@geronimo.apache.org
> <ma...@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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Fwd: Certification Authority (CA) portlet
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <hc...@gmail.com> 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* <hcunico@gmail.com
> > <ma...@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
> > <ma...@gmail.com>
> > > <mailto: hcunico@gmail.com <ma...@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
> > <ma...@gmail.com>
> > > <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>
> > > > <mailto: c1vamsi1c@gmail.com <ma...@gmail.com>
> > <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>>>
> > > > Date: Oct 6, 2006 11:59 AM
> > > > Subject: Certification Authority (CA) portlet
> > > > To: dev@geronimo.apache.org
> > <ma...@geronimo.apache.org> <mailto:dev@geronimo.apache.org
> > <ma...@geronimo.apache.org>>
> > > <mailto: dev@geronimo.apache.org
> > <ma...@geronimo.apache.org> <mailto:dev@geronimo.apache.org
> > <ma...@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
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: Fwd: Certification Authority (CA) portlet
Posted by Hernan Cunico <hc...@gmail.com>.
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* <hcunico@gmail.com
> <ma...@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
> <ma...@gmail.com>
> > <mailto: hcunico@gmail.com <ma...@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
> <ma...@gmail.com>
> > <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>
> > > <mailto: c1vamsi1c@gmail.com <ma...@gmail.com>
> <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>>>
> > > Date: Oct 6, 2006 11:59 AM
> > > Subject: Certification Authority (CA) portlet
> > > To: dev@geronimo.apache.org
> <ma...@geronimo.apache.org> <mailto:dev@geronimo.apache.org
> <ma...@geronimo.apache.org>>
> > <mailto: dev@geronimo.apache.org
> <ma...@geronimo.apache.org> <mailto:dev@geronimo.apache.org
> <ma...@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
> > >
> > >
> >
> >
>
>
Re: Fwd: Certification Authority (CA) portlet
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
That should go as part of Keystore portlet (may be), but not CA portlet.
Vamsi
On 10/10/06, Hernan Cunico <hc...@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
> > <ma...@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
> > <ma...@gmail.com>
> > > <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>>
> > > Date: Oct 6, 2006 11:59 AM
> > > Subject: Certification Authority (CA) portlet
> > > To: dev@geronimo.apache.org <ma...@geronimo.apache.org>
> > <mailto: dev@geronimo.apache.org <ma...@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
> > >
> > >
> >
> >
>
Re: Fwd: Certification Authority (CA) portlet
Posted by Hernan Cunico <hc...@gmail.com>.
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
> <ma...@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
> <ma...@gmail.com>
> > <mailto:c1vamsi1c@gmail.com <ma...@gmail.com>>>
> > Date: Oct 6, 2006 11:59 AM
> > Subject: Certification Authority (CA) portlet
> > To: dev@geronimo.apache.org <ma...@geronimo.apache.org>
> <mailto: dev@geronimo.apache.org <ma...@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
> >
> >
>
>
Re: Fwd: Certification Authority (CA) portlet
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <hc...@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 >>
> > Date: Oct 6, 2006 11:59 AM
> > Subject: Certification Authority (CA) portlet
> > To: 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
> >
> >
>
Re: Fwd: Certification Authority (CA) portlet
Posted by Hernan Cunico <hc...@gmail.com>.
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
> <ma...@gmail.com>>
> Date: Oct 6, 2006 11:59 AM
> Subject: Certification Authority (CA) portlet
> To: dev@geronimo.apache.org <ma...@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
>
>
Fwd: Certification Authority (CA) portlet
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <c1...@gmail.com>
Date: Oct 6, 2006 11:59 AM
Subject: Certification Authority (CA) portlet
To: 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