[06:52:17] argg.scom.ca [root:0]
/usr/local/src/net/httpd-2.4.56.current/support
# gmake
gmake[1]: Entering directory
'/usr/local/src/net/httpd-2.4.56.current/support'
/usr/local/apr/build-1/libtool --silent --mode=link cc -g -O2
-L/usr/local/lib -o htpasswd htpasswd.lo passwd_common.lo
Happy Wednesday
Ok allow me to share some experience :
about 4 years ago 1one1 hosting, myself and a bunch of others got hacked.
this is because i was using common vhosts pointing to the web directory
because www:www were the rights (no real easy way to get around that) i
had to lock php
wordpress - but use a mirroring script to serve
the site as predominantly static {takes careful design to do this!}
-Original Message-----
From: Paul Kudla (SCOM.CA Internet Services Inc.)
Sent: 06 July 2022 11:29
To: users@httpd.apache.org
Subject: Re: [users@httpd] site compromised and http
this is how my ssl, vhosts, redirects are setup maybe this will help
note any ssl website name MUST equal a valid certificate or you will get
a cert mismatch error !!
granted there are several cert authorities (free ssl etc) i have found
its just easier to get a resale account (lots of
ok may or may not be related but i found i had to lock php, wordpress
etc down heavely in apache
especially if you are using vhosts
i found one authorized site could talk to another without making things
more strict
yes its a pain to have one vhost per site but its the only way to fully
please note that changing the site around
you will also have to update your dns to point to the webserver
ie : basecolldev.mydomain.fr
needs a dns lookup
otherwise apache virtual hosts would get setup to match
fyi
Happy Wednesday !!!
Thanks - paul
Paul Kudla
Scom.ca Internet Services
Ok to clarify (this is standard apache from day one moving from
convential SSL certs towards SNI used today)
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 80
#Listen 443
the
ok this is starting to make more sense as we go along
I went through all of this myself when setting up origionally
i found that i can not use vhosts easily with ssl / sni / sans etc
and san is a nightmare to manage everytime you make a cert change.
it was just more reliable to use
you need to set the cert files per virtual domain
example :
ServerName underconstruction.scom.ca
ServerAlias underconstruction.scom.ca
DocumentRoot /www/underconstruction.scom.ca
SSLEngine on
SSLProtocol all
SSLCertificateKeyFile /www/scom.ca/ssl/scom.ca.key
SSLCertificateFile
ok san is only useable if the cert is setup that way
i bought a proper *.scom.ca wildcard ssl cert for my domain
i then buy mail.xxx.com certs for the other domains
sni works well when configured this way.
granted san might or might not work (i never tries that) however san was
designed
10 matches
Mail list logo