On Mon, 2009-12-14 at 12:34 -0500, Dans, Raymond (CAR:9D30) wrote:
> Scott wrote:
> >To: sipXecs developers
> >Subject: [sipX-dev] Distributing SSL CA certificates (and 
> >other files not known at build time)
> >
> >We've got a few activities in progress to improve our 
> >management of certificates, and specifically of Certificate 
> >Authority certificates.
> >
> >One aspect that has not been addressed yet is replication of 
> >those authorities to distributed systems.  If we have a 
> >service that uses TLS on a distributed system, that service 
> >may need to validate peer certificates using authority 
> >certificates other than our private one.
> >
> >The current file replication mechanism through sipXsupervisor 
> >requires that the file to be replicated be declared in the 
> >process definition of some service.  Since we don't know in 
> >advance what the names (or even
> >number) of additional CA certificates might be, we'll need to 
> >extend the supervisors capabilities and what a service can 
> >declare in its process definition.
> >
> >I can think of two possible approaches:
> >
> >     A. Allow the declaration of a directory, which would allow the
> >        replication of any file whose directory path matches the
> >        directory.  A process might declare:
> >                
> >                <directory>/etc/sipxpbx/ssl/authorities</directory>
> >                
> >     B. Provide for a file glob or regular expression match for file
> >        names.  The process definition might include:
> >
> >                <file 
> >pattern='true'>/etc/sipxpbx/ssl/authorities/*.crt</file>
> >
> >Thoughts?
> >
> 
> I think I prefer A over B just because for the certificate authorities,
> we don't necessarilly know the suffix as it may be different than what
> we use.

Which is a problem, actually.  Our certificate hashing and validation
routines rely on all certificate files using the suffix '.crt', so we
need the upload interface to enforce (or convert) that.


_______________________________________________
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/

Reply via email to