I am running a virtual server (Ubunto, Plesk 12). For the vhosts the settings are stored in httpd.conf, which is generated by Plesk.
When having activated SSL-Support in Plesk, then Plesks default certificate is referenced, even when no certificate has been selected. Trying to override this value via vhost_ssl.conf results in Apache not being able to start/ restart. My tech support told me, that Apache is trying to bind both certificates then, instead of overriding the SSLCertificateFile directive.
When having SSL-Support deactivated in Plesk, then all directives regarding SSL (< IfModule mod_ssl.c >) are missing in httpd.conf. I guess additional directives within vhost_ssl.conf wont work then.
Is there any other way to replace/ override the default certificate? It is no option to put the setting into httpd.conf directly (iE via VI), because once I make a change in Plesk related to this file, it is overwritten. It is also no option, to put the certificates keys into Plesk, because they need to be updated regulary and I dont want to do that manually every time.
You can apply your certificate for domain if you upload certificate to subscription's repository here:
Also you can try LetsEncrypt extension from Extensions Catalog.
By the way, Plesk's LetsEncrypt extension updates all it's certificates by cron task every month:
Related
My Node.Js Bitnami Lightsail instance had its frontend code at /opt/apache/htdocs and http://example.com was working perfectly pointing to that directory (my backend located under opt/projects).
After executing Certbot LetsEncrypt my domain is now pointing to a different folder /var/www/html
Please advise on:
In certbot instruction page I choose Apache for "My HTTP website is running", there wasn't a Bitnami option, was that the right call?
Is this the right configuration and just move my code to html folder?
Does my backend code has to move too? if so where?
Any other well-known issues that I might face?
Cheers.
Bitnami Engineer here,
We do not have any guide to configure certbot and Bitnami, but we have a guide that helps you configure the Let's Encrypt SSL certificate using lego. We have a tool that configures everything so you do not need to worry about editing the Apache's conf files or setting the renew process.
sudo /opt/bitnami/bncert-tool
You can learn more about it here.
In case you want to manually create a SSL certificate, you can also run the lego tool directly
sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run
You will later need to configure the Apache's conf files to use that new certificate file. You can learn more about it here
Note: If you used certbot and it modified the Apache's configuration, you will need to undo those changes to use the proper folder. You will need to review the /opt/bitnami/apache2/conf/httpd.conf, /opt/bitnami/apache2/conf/bitnami/bitnami.conf and /opt/bitnami/apache2/conf/vhosts/* files
I have multiple virtual hosts on the same server using CentOS 6. After running sudo ./path/to/certbot-auto --apache I have successfully installed a certificate for a website https://domain1.example. Browser confirms that the certificate is issued to Common Name (CN) domain1.example.
However, after repeating the same procedure for domain2.example, browser is warning that the connection is not secure and the certificate is issued to Common Name 192.168.1.5, which is a local IP address of the server. Why isn't the Common Name correctly determined for domain2.example? What could be the reason?
Without https:// the website http://domain2.example is working properly.
It turns out the problem was due to the /etc/httpd/conf.d/ssl.conf file which enables SSL for Apache. Since CentOS loads all Apache conf files in alphabetical order, only those conf files will be using SSL which come after ssl.conf in alphabetical order. All files that come before will not be recognized for SSL.
In my case conf file for domain1.example came after ssl.conf and thus was recognized for SSL. But the conf file for domain2.example was before ssl.conf and therefore was ignored. A simple renaming ssl.conf to 000-ssl.conf put that file on top of the list and all the other files were loaded correctly.
I have an apache server configured with multiple NameVirtualHosts running on the same IP. This all works fine.
However, because of the "include conf.d/*" directive, apache also picks up config for cacti and phpmyadmin, which add in aliases for /cacti and /phpmyadmin, and those aliases appear to be valid for all virtualhosts. That is to say, I can go to http://firstvirtualhost/cacti and also http://secondvirtualhost/cacti, and I get the same page.
In my case, the default namevirtualhost is publicly visible, and I do not want tools like phpmyadmin or cacti to be visible under that URL
In fact, I don't want any random package to be able to make itself visible across all virtualhosts simply by creating a file for itself in conf.d.
You have to delete the line include conf.d from the global Apache configuration file, and optionally add it to your own private virtual host configuration file.
I have setup Apache2 with SSL on a Debian Linux (squeeze) box. In the /etc/apache2/sites-available/default-ssl the SSL Engine is already configured and working. Packages with web software often come with an extra pkg-apache.conf file with some virtualhost, alias and directory directives. How could I make such package available via https without putting the content of pkg-apache.conf into default-ssl? Adapting the to *:433 results in load errors.
You can use the Include directive within your SSL virtual host to point to your extra configuration file. You'll need to make sure that the directives within that extra file can be used within a VirtualHost section.
I am running a multi-language web store accessible from differents domains, that lead to different languages.
The apache configuration is quite complex and I would like to have one single file shared with all the stores. I had this in place until I had to introduce SSL.
When it comes to apache and SSL certificates I would need to do something like:
SetEnv is_es 0<br>
SetEnvIfNoCase Host .*es is_es 1<br>
SSLCertificateFile /etc/ssl/certs/spanish.server.crt env=is_es<br>
This is aparently not possible, apache tells me:
<i>SSLCertificateFile takes one argument, SSL Server Certificate file (`/path/to/file' - PEM or DER encoded)</i>
I was wondering if there is any workaround. My goal is to avoid having different copies of the same configuration and having to propagate manually any changes I want to make.
It is hosted on a dedicated server, so I am free to do any changes to the setup.
When you are on a https connection, the Host header is inside the SSL encapsulation, so you need the full SSL handshake before you check for an hostname for your virtualhost.
You should go for SSL certificates with SAN (Subject Alternative Names), this will allow that a single certificate for multiple hostnames. (or a wildcard cert)
All the main browsers supports it already:
http://www.digicert.com/subject-alternative-name-compatibility.htm
And you can get one of this certs from the majors CAs:
http://www.digicert.com/subject-alternative-name.htm
http://www.verisign.com/ssl/buy-ssl-certificates/subject-alternative-name-certificates/index.html
http://www.thawte.com/ssl/san-uc-ssl-certificates/index.html