[olug] Building a web server for both security and performance in 2011

Thu Sep 1 16:36:40 UTC 2011

Does a wildcard cert show any different in the browser (I assume if you 
display info on the cert it would say it is a wildecard but not many 
people display info on the cert).  I think godaddy offers multiple host 
certs as well.  I've never actually purchased either of these (wildcard 
or multi-host certs) so I don't know if they appear any different to the 
end user or not.

On 9/1/11 10:41 AM, Kevin wrote:
> You might be able to use a wildcard cert for private1.foo.com and
> private2.foo.com, but to get a wildcard cert for .com......yeah, that
> won't go over well.
>
> What MIGHT work(and I don't know how) is if you can tell your SSL Cert
> vendor to use a public key that I provide(and that I get from the
> public key of the existing domain.
>
> On Thu, Sep 1, 2011 at 10:37, Sam Tetherow<tetherow at shwisp.net>  wrote:
>> Can't you use a wildcard cert for this?
>>
>> On 9/1/11 10:05 AM, Lou Duchez wrote:
>>> Hard for me to say for sure, I'm not the best test environment, and mostly
>>> I'm using the certificates for Email.  I remember doing some quick testing
>>> with the StartSSL certificate and the Web server, and I think it worked okay
>>> on IE and Opera (and possibly Firefox), but I didn't test extensively.
>>>
>>> This discussion reminds me of a sad truth about SSL and HTTP: you can have
>>> only one zone / domain certificate per port.  In other words, if you've got
>>> two domains ("foo.com" and "bar.com") and you want to set up SSL sites for
>>> "secure.foo.com", "secure.bar.com", "private.foo.com", and
>>> "private.bar.com", they all have to be on different ports, and only one of
>>> them can get the coveted default port of 443.  This is because the SSL is
>>> sorted out long before the HTTP request's headers have been picked apart, so
>>> the Web server can't look for the "right" certificate only after figuring
>>> out which virtual domain the request is for.  Rather, the Web server has to
>>> decide which certificate based on the port, and once that's done, the HTML
>>> headers had better agree with the certificate.
>>>
>>> I would say it's worth trying startssl.com; at most it will cost you time,
>>> not money.  Think of it this way: you can experiment with domains you really
>>> don't have any interest in securing, without feeling like a chump who wasted
>>> $50.
>>>
>>>
>>>> Does StartSSL present a warning to unmomdified IE/Firefox/Safari/Chrome?
>>>>
>>>> On Thu, Sep 1, 2011 at 09:18, Lou Duchez<lou at paprikash.com>    wrote:
>>>>> I've been experimenting with SSL from startssl.com.  It's free, and it
>>>>> seems
>>>>> to work well enough so far.
>>>>>
>>>>> Also, where my Web apps require a login / password, I try to hook them
>>>>> into
>>>>> Fail2Ban, so that repetitive failed logins trigger a temporary IP ban
>>>>> and an
>>>>> E-Mail to the admin.
>>>>>
>>>>>> generally, yes, the big issue we ran into with selinux was having a web
>>>>>> page be able to gpg a file
>>>>>>
>>>>>>
>>>>>> I'd add to my list run ssl - for $50 at godaddy (or less other places),
>>>>>> there's almost no reason not to
>>>>>>
>>>>>>
>>>>>>
>>>>>> -barry
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 8/31/2011 11:26 PM, Kevin wrote:
>>>>>>> On CentOS/RHEL, SELinux is actually not all that bad. Certainly on any
>>>>>>> system I was hardening, I would enable it.
>>>>>>>
>>>>>>> On Wed, Aug 31, 2011 at 18:36, Barry Von Ahsen<barry at vonahsen.com>
>>>>>>>   wrote:
>>>>>>>> generally I:
>>>>>>>>
>>>>>>>> * don't load/remove modules I don't need
>>>>>>>> * remove the dumb default .conf files my distro adds (centos/rhel)
>>>>>>>> * run mod_security
>>>>>>>> * run php-suhosin
>>>>>>>>
>>>>>>>> in theory, also run selinux/apparmor, but it's usually been more
>>>>>>>> trouble
>>>>>>>> than it's worth
>>>>>>>>
>>>>>>>> -barry
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/30/2011 04:51 PM, T. J. Brumfield wrote:
>>>>>>>>> I've tried to keep up on best practices over the years, but I'm
>>>>>>>>> always
>>>>>>>>> wondering if there are tips and tricks out there that I'm not aware
>>>>>>>>> of,
>>>>>>>>> especially when it comes to securing a web server.
>>>>>>>>>
>>>>>>>>> If you were putting together a standard for a web Linux server
>>>>>>>>> today,
>>>>>>>>> what
>>>>>>>>> would you recommend?
>>>>>>>>>
>>>>>>>>> -- T. J. Brumfield
>>>>>>>>> _______________________________________________
>>>>>>>>> OLUG mailing list
>>>>>>>>> OLUG at olug.org
>>>>>>>>> https://lists.olug.org/mailman/listinfo/olug
>>>>>>>> _______________________________________________
>>>>>>>> OLUG mailing list
>>>>>>>> OLUG at olug.org
>>>>>>>> https://lists.olug.org/mailman/listinfo/olug
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OLUG mailing list
>>>>>>> OLUG at olug.org
>>>>>>> https://lists.olug.org/mailman/listinfo/olug
>>>>>> _______________________________________________
>>>>>> OLUG mailing list
>>>>>> OLUG at olug.org
>>>>>> https://lists.olug.org/mailman/listinfo/olug
>>>>> _______________________________________________
>>>>> OLUG mailing list
>>>>> OLUG at olug.org
>>>>> https://lists.olug.org/mailman/listinfo/olug
>>>>>
>>>> _______________________________________________
>>>> OLUG mailing list
>>>> OLUG at olug.org
>>>> https://lists.olug.org/mailman/listinfo/olug
>>> _______________________________________________
>>> OLUG mailing list
>>> OLUG at olug.org
>>> https://lists.olug.org/mailman/listinfo/olug
>> _______________________________________________
>> OLUG mailing list
>> OLUG at olug.org
>> https://lists.olug.org/mailman/listinfo/olug
>>
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://lists.olug.org/mailman/listinfo/olug