Facebook
Twitter
W
WillemK
Guest
I have the following setup
OpenVZ vps with 2 2 adressess
clean centos 5.5 64 bit install, no httpd, no mysql and no php, just YUM and sshd
yum upgrade lists no packages for upgrade.
I then install plesk and all it's dependencies with
I install 10.0.1, all default options (though i reproduced it with minimum options as well, ie. no business manager)
I setup the main ip address as exclusive, and the second one as shared.
I add one wildcard ssl certificate (*.domain.com) to the admin repository. I use it to secure the control panel, and make it the default certificate for the exclusive ip. It works as it should for the control panel at this point.
I then add a subscription for the the same domain I want protected. I make sure ssl is enabled, and in global webhosting settings for the subscription it gives the correct certificate name. I also verified the domain definitely is hosted on the right (exclusive) ip address.
so i now have
https://domain.com:8443 which works as it should, ssl and everything.
however https://domain.com/ (or every other subdomain) returns a completely different certificate.
It's not the certificate I created, and not the automatically generated self signed plesk certificate.
After some digging, it seems to return the certificate configured in /etc/httpd/conf.d/ssl.conf
<VirtualHost _default_:443>
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
Any domains I create on the shared ip address (which still has the default certificate as default certificate) correctly return the default plesk certificate.
As far as I can see, everything is configured as it should in plesk.
The file /var/www/vhosts/domain.com/conf/vhost.conf seems to have the correct ssl certificate specified (it points to /usr/local/psa/var/certificates, and i verified with 'openssl x509 -text -in certname' that it was mine)
Am i just overlooking something, or is this a bug?
If I change the exclusive ip address to a shared ip-address, everything works correctly, so that leads me to believe that the configuration is right, and this is bug. Fortunately that is also the workaround, though it took me quite some fiddling to find that out.
Hope this helps someone
Willem
OpenVZ vps with 2 2 adressess
clean centos 5.5 64 bit install, no httpd, no mysql and no php, just YUM and sshd
yum upgrade lists no packages for upgrade.
I then install plesk and all it's dependencies with
I install 10.0.1, all default options (though i reproduced it with minimum options as well, ie. no business manager)
I setup the main ip address as exclusive, and the second one as shared.
I add one wildcard ssl certificate (*.domain.com) to the admin repository. I use it to secure the control panel, and make it the default certificate for the exclusive ip. It works as it should for the control panel at this point.
I then add a subscription for the the same domain I want protected. I make sure ssl is enabled, and in global webhosting settings for the subscription it gives the correct certificate name. I also verified the domain definitely is hosted on the right (exclusive) ip address.
so i now have
https://domain.com:8443 which works as it should, ssl and everything.
however https://domain.com/ (or every other subdomain) returns a completely different certificate.
It's not the certificate I created, and not the automatically generated self signed plesk certificate.
After some digging, it seems to return the certificate configured in /etc/httpd/conf.d/ssl.conf
<VirtualHost _default_:443>
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
Any domains I create on the shared ip address (which still has the default certificate as default certificate) correctly return the default plesk certificate.
As far as I can see, everything is configured as it should in plesk.
The file /var/www/vhosts/domain.com/conf/vhost.conf seems to have the correct ssl certificate specified (it points to /usr/local/psa/var/certificates, and i verified with 'openssl x509 -text -in certname' that it was mine)
Am i just overlooking something, or is this a bug?
If I change the exclusive ip address to a shared ip-address, everything works correctly, so that leads me to believe that the configuration is right, and this is bug. Fortunately that is also the workaround, though it took me quite some fiddling to find that out.
Hope this helps someone
Willem
