Thanks for the details Vamsi.
Not that it will be used a lot (a migration scenario) but do you have any plans
for exporting a whole keystore (and then choose the type) feature?
Cheers!
Hernan
Vamsavardhana Reddy wrote:
Hernan,
In the "Issue New Certificate" function, there is no selection of JKS or
p12. The CA will only be generating a certificate and the certificate
is usually provided in a base64 encoded text. Once the requestor
receives this text file, he/she will need to import this certificate
into a keystore or browser where ever the private key is stored.
Regarding search, search based on more criteria is needed. I am
evolving this as I am going about develpoing the CA. The simplest
search (and only search as of now) is based on serial number as the
certificates are now stored as <serial-number>.txt. To support other
criteria (in an efficient way) the certificates may need to be stored
differently.
N2: A PKCS10 requests will have the name information and public-key
combined into a sequence and signed using the private-key. This is
usually generated by tools like keytool. Some browsers support a KEYGEN
tag which will make the browser generate a keypair, combine the
public-key along with a "challenge" phrase, sign the same (known as
SignedPublicKeyChallenge) and send it to the server when the form is
submitted. CA should be able to handle both the formats for the
requests (and any other commonly used formats, like self-signed
certificate).
Once the CA is setup, CA will need an interface (I call this "CA Helper
App" as of now) using which certificates can be requested and downloaded
etc. I am in the process of developing a sample application. For a
certificate request received, processed and user downloads certificate,
a typical workflow would be.
Step 1: A user submits a certificate request by accessing a "Request
Certificate" page in the application through the web browser. What
happens at this step is that the browser generates a keypair, and sends
tha public key (packaged as a SignedPublicKeyAndChallenge) and name
information to the application. Application saves this information in a
"CertificateRequestStore" and provides an request-id to the user.
Step 2: CA accesses all these requests in the "CertificateRequestStore"
in a screen in the CA portlet under "List Requests waiting verification"
and approves or rejects the requests. In a real-world scenario, CA will
have to verify the details provided by the requestor etc. Once
approved, the request will showup in "List Requests ready to be fulfilled".
Step 3: CA accesses the requests ready to be fulfilled and processes the
request by issuing a certificate. This certificate is stored in the
"Certificate Store" and the fufilled request is removed from the
"Certificate Request Store".
Step 4: User will visit a "Download Certificate" page in the "CA Helper
App", provides the request-id given to him (in Step 1) and downloads
his/her certificate. The "CA Helper App" will upload the ceritificate
to the user's web browser with appropriate mime-header. The browser
will store the certificate along with the private key and the
certificate is ready for use.
I have implemented most of it and am testing the code. I am still using
1.1.1 code base for development since trunk is unstable and I do not
want to be blocked by build failures. Once I complete the testing I
will test the code by integrating it into trunk, create a patch and
submit to JIRA. It will be a couple of days more before the new patch
will showup in the JIRA.
Thanks,
Vamsi
On 10/10/06, *Hernan Cunico* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Vamsi,
I still have not had the chance to check the patch (GERONIMO-2413)
but I do have a few questions form your first note.
4. can you select JKS or p12 in this step? I'm thinking in client
certificates -> HTTPS with Client Authentication scenario
5. in addition on entering the serial #, any chance to list the
existing certificates in the CertificateStore? maybe CN + Alias
N1. does that mean that the CSR will be provided as a text file (on
a specific location) and the portlet will pick them up and list
them? if so, that would be great and a similar structure should be
in place for already signed certificates.
N2. could you expand?
As for IE, I can't find a nice way to say what I think about IE and
VBScripts. All I can say is that probaly 80% or more ( just a wild
guess ) of the users are using IE. Using another browser to
create/retrieve/export the certificate and then import it into IE
does not look like a healthy workaround. Can we add something else
on the server side to "fill-in-the-blanks" from IE?
Cheers!
Hernan
Vamsavardhana Reddy wrote:
> Hi All,
>
> I have not seen any replies to my last post :(
>
> I have identified a few more function required. These are for the
> work-flow a CA might want to follow:
> 1. List Requests: There should be two pages instead of one.
> A) Listing of requests that are received and need to be
> verified (once verified, the request will reach a second list)
> B) Listing of requests that are verified and ready to be
fulfilled.
> 2. Logging: CA should have a separate log of requests received,
> verified, fulfilled, certificates revoked etc.
>
> Comments? Suggestions? Pointers?
>
> Thanks,
> Vamsi
> ---------- Forwarded message ----------
> From: *Vamsavardhana Reddy* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
> Date: Oct 6, 2006 11:59 AM
> Subject: Certification Authority (CA) portlet
> To: [email protected] <mailto:[email protected]>
<mailto: [email protected] <mailto:[email protected]>>
>
> Hi All,
>
> I have uploaded a minimal version of Certification Authority (CA)
> portlet to the JIRA. See
> http://issues.apache.org/jira/browse/GERONIMO-2413 . The JIRA
also has
> some screenshots. I do not know if anyone has got a chance to
try out
> the portlet. Here is an overview of this portlet's functions.
>
> 1. Setup Certification Authority: The "CA home" page checks if
the CA
> has already been initialized. If not, it will provide access to only
> this function viz. " Setup Certification Authority". This function
> enables the user to provide details of CA's identity, algorithm
> parameters for CA's keypair & signature algorithm, a serial
number for
> CA's self-signed certificate, validity period for CA's keypair and a
> password to protect CA's privatekey. Once the details are
submitted, a
> keypair and self-signed certificate are generated and stored in
> "ca-keystore". CA portlet uses KeyStoreGBean to manage its own
keypair
> and certificate.
>
> 2. Lock and Unlock CA: Once the CA is setup, upon a fresh login to
> Geronimo Console, users will notice that the CA is in locked state.
> "Unlock CA" function lets the user unlock the CA by providing CA's
> privatekey password (provided at the time of CA setup). Once
unlocked,
> the user will have access to the CA functions. "Lock CA"
function locks
> the CA.
>
> 3. View CA Details: This function enables the user to see the
details
> of CA' certificate and the highest serial number used to by the CA.
> Base 64 encoded certificate text on this screen can be
copy+pasted into
> a text file and sent to the requestor to designate this CA as
trusted CA
> in their software.
> (Note: CA stores the serial number used at the time of setup and
> increments it each time a certificate is to be issued.)
>
> 4. Issue New Certificate: This functions lets the CA issue a new
> certificate by processing the Certificate Signing Request
(CSR) text.
> Upon pasting the CSR text into a textarea and submitting, a
screen will
> show the requestor name and public key details from the CSR and
lets the
> user enter validity period and select the signature
algorithm. The next
> screen will show all details and ask for confirmation. Once
confirmed,
> a certificate is issued and stored in a "CertificateStore". The
screen
> will show the details of the certificate issued. Base 64 encoded
> certificate text on this screen can be copy+pasted into a text
file and
> sent back to the requestor.
>
> 5. View Issued Certificate: This function lets the user view a
> previously issued certificate by providing the certificate serial
number.
>
> More work on the way:
> After posting the patch to JIRA, I have found the necessity for a few
> other functions:
> N1. List Requests: This function will list all the certificate
> requests that are waiting to be fulfilled and provide a link on each
> request-id so that the user can click on the links (instead of
entering
> the csr text in a textarea) and proceed directly to entering
certificate
> validity details etc.
> N2. Process a certificate request based on (Name Attributes +
> SignedPublicKeyAndChallenge): Users requesting a certificate
through
> web browsers may not be able to submit a PKCS10 Certificate Request.
> Netscape, Firefox (and other browsers??) support a KEYGEN form
tag that
> will let the browser, upon form submission, generate a key pair,
combine
> the PublicKey & a Challenge string and sign (this is the
> SignedPublicKeyAndChallenge), encode this information in base64
and send
> it along with other form fields. In this case, name attributes
are not
> part of a "signed" request and need to be collected separately.
> N3. CA helper application: This application will be the
interface for
> users using their web browsers to request a certificate from the CA.
> This application will have
> a) A page with KEYGEN tag to receive
SignedPublicKeyAndChallenge along
> with name attribute values from the requestor.
> b) A link using which the users can download and install CA's
> certificate into their browsers as a trusted certificate.
> c) A page from which the users can download and install the
> certificate issued to them by the CA.
> This application can store the requests so that the CA portlet can
> pickup these and show in "List Requests" page.
>
> To be explored:
> How to do this KEYGEN equivalent through Internet Explorer? I
know that
> it requires some VBScript to generate a (PKCS10?) certificate
request
> through Internet Explorer. I have done this way back in 1998 and
don't
> remember any details now :o(
> A work around would be to make the users use a browser supporting
KEYGEN
> tag to request and download their certificate. The certificate and
> privatekey can then be exported and imported into IE. (I don't like
> this work around. Or should this be the only option we provide??)
>
> For later:
> CRLs etc.
>
> Any suggestions, comments? Anything I am missing? Am I heading
in the
> correct direction?
>
> Thanks,
> Vamsi
>
>
