On Thu, 2009-12-17 at 10:11 -0500, Paul Mossman wrote: > Mircea wrote: > > I was thinking about XX-6905 resolution and I need some clarification > > > > http://track.sipfoundry.org/browse/XX-6905 > > Need to be able to create a certificate for the web UI that uses a > name other than the hostname > > > > Comment from Scott: > > > > "It should also be possible to upload both the key and certificate > generated outside the system > > and just validate that they are compatible"
> Is this the same requirement as Scott's "B." in > http://track.sipfoundry.org/browse/XX-7249 ? Not quite, but they are related. The current interface for generating a web certificate does two things: 1. Generates a public/private key pair 2. Creates a CSR (an unsigned public key) containing the full hostname of the system. the user is then expected to take the CSR to a CA to be signed, which is what produces a certificate (a certificate is essentially just a public key with metadata and a signature). XX-6905 says that we should allow the creation of a CSR that uses some alias for the hostname: the systems real fqdn might be 'ds12r5s7.example.com' (because that's the corporate standard form my hostnames must have - identifying the datacenter, rack, and shelf), but I want my users to log in using 'voicemail.example.com', or 'sipxecs.example.com'. XX-7249 is a related problem - the current interface cannot be used with a CA that is set up to generate the public/private key pair in the CA service so that the service has a copy of the private key and provides both the private key and the signed certificate as one step [1]. It should be possible to import the combination of a private key and a certificate, even though sipXconfig was not used to generate either (and that certificate may well not use the fqdn of the system - hence the relationship between the issues). As for checking certificates - in both cases, the check-cert.sh script should be invoked to do any checking. [1] Whether or not designing a CA that way is an interesting discussion, but not really in scope here... we want to support it because customers do it. _______________________________________________ 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/
