On Fri, Nov 20, 2009 at 3:32 PM, Paul Mossman <[email protected]>wrote:
> Scott wrote: > > On Fri, 2009-11-20 at 02:08 +0200, Mircea Mihai Carasel wrote: > > > > > > > UI proposal: Please take a look at attached screenshots: > > > http://track.sipfoundry.org/browse/XX-6850 > > > ..and share your comments :) > > > > Raymond is (or will shortly be) working on a java framework > > for using the pem format keys used by the C++, eliminating > > the use of java keystore and trustore completely. > > > > http://track.sipfoundry.org/browse/XX-7058 > > > > That won't remove the need to load new trusted certificate > > roots, but we certainly don't want to use the term > > 'truststore': use 'Trusted CA Certificate'. > > > > We don't need a password field - certificates won't have > > passwords on them. > I was under impression that we want to upload an entire truststore file (that contains a list of certificates, like the JDK default cacerts file) - this would require a password But actually I suppose that what we want, is to upload separate certificate files in PEM format by doing the following: [From SCOTT] When a new certificate is uploaded, the screen should: 1. Validate it (I can do a quick change to an existing script to make this easy) 2. Display it for the user to get confirmation that this is what they meant to upload 3. Copy it into the $SIPX_CONFDIR/ssl/authorities directory 4. Execute $SIPX_BINDIR/ssl-cert/ca_rehash Also, I suppose that point 4.: $SIPX_BINDIR/ssl-cert/ca_rehash inserts the uploaded certificate into sipX's authorities.jks (We don't need any sipXconfig magic to do that :) ). Is this correct? > > > I suggest calling this the Certificate Authorities page. > > Could it be put under the existing System -> Web Certificates menu? > Yes, it could - we will upload separate certificate files instead of a entire truststore file - so the current Web Certificates UI can be reused (with suggested changes from Scott and you Mircea > > The two existing pages could be renamed to Generate CSR and Import > Certificate. > > Also if we're going to be using HTTPS more in the future, the existing > CAs should be made available in the various formats expected by hard > phones and OSs. i.e. As text, as a file, and as an HTTP URL. The SHA1 > fingerprint would also be good, as Polycoms display this for > confirmation when installing a custom CA. > > > -Paul > [email protected] > > > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ >
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
