William A. Rowe, Jr. wrote: > Jorge Schrauwen wrote: >> Do note that not all users that will chose the SSL package will know how >> to correctly fill in the fields. > > s/not all/a small minority of/ > > They can't figure out what Domain Name means, let's be serious :) > >> On 1/10/07, *Issac Goldstand* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> I think the MSI should autogenerate a self-signed cert at least (last >> thing we need is for people to deploy a static pre-distributed cert >> which would make it that much easier to do man-in-the-middle attacks). > > I agree, static keys are only for pure localhost-style examples, just a bad > idea for something this flexible. As far as a default selfsigned cert, > I was thinking of using the server name they filled in already as it stands, > and let them replace it with a worthwhile one.
You mean as the default entry, right? It should be changeable (and should affect the ServerName in the default SSL virtualhost, of course) > >> Would be great if the MSI had a choice to use an existing cert, or >> generate a new one with a user supplied DN (fill-in fields for CN, OU, O >> , L, ST, C), and generated a self-signed cert with that + a .csr for >> sending to a Trusted Third-Party for signing. >> >> Would also be great if there was some GUI for importing a signed cert >> post-install, similar to the IIS wizard, but that's probably pushing it. > > Well, there are dozens of utilities out there that do that, I'm not compelled > in the least to add it to the httpd package. As I said, that's probably pushing it :-) > > Justin Erenkrantz wrote: >> I'd prefer to just point them at the instructions for generating their >> own key rather than us distributing a 'fake' one. -- justin > > ./configure; make; make install > > We don't deposit a certificate today for Unix. After considering this a bit > more, I agree with jerenkrantz. Didn't there used to be a make cert in the Apache 1.3 days? I distinctly remember having that option at some point, though it may have been from a modified source, like an SRPM or something... > At least, initially. I'd rather see something out the door, with all the > appropriate comments in the user community of the best way (in their opinion) > to proceed. IMHO, that's like saying that the MSI shouldn't install the windows service for you, or modify the default .conf files to suit your install. If you want to do it this way, distribute a binary .zip If we're putting it in a GUI installer that knows how to prepare the initial environment, this should definitely be one of the things it does... > > Then if we really believe the server install should do something to either > help deposit a cert/key for their server, or a post-install command should > be provided for this purpose, then we should ensure win and unix are offering > the exact same facility. > I'll look around for the make cert rule that I remember seeing. Should be very simple to do this for unix, assuming an openssl binary exists and is on the path Issac
