How difficult is it to write these scripts? Does it make it harder considering the DNS Records reside on my registrar's site, while the commands run locally in the terminal?
That depends on how easy the other parties make it. If they offer an east API, then it isn't very hard. Of they only offer web-based control over the DNS zone, well, good luck.
Alternatives could be stuff like acme-dns.
2 Likes
I agree, the most complicated part is the DNS API.
[completely out of your control]
That said, you could delegate the DNS entry to any other DNS Service Provider (DSP) that supports DNS updates via API.
OR
Delegate them to yourself and handle them via acme-dns.
3 Likes
Bluehost does appear to have some level of API access to DNS records they host (assuming I found the right Bluehost. For instance, Adding TXT Record. Though they refer to it as a "Reseller" API which might mean only reseller accounts have access. This would be a question for their support team.
However, there's no requirement that your domain registrar and DNS hosting provider need to be the same company. Even before you migrate the domain registration to Bluehost, you could move just the DNS hosting to somewhere else (like Cloudflare) which has known good DNS plugins for certbot. That's the direction I'd personally go rather than complicating matters with things like acme-dns that involve delegation.
Registrar based DNS hosting is typically pretty bottom-of-the-barrel in terms of reliability and the tools available to manage it. But most throw it in for free with the cost of registration because customers don't often know or care about the difference between it and a real DNS hosting provider.
5 Likes
Question regarding this next step;
I want to enable SSL or TLS, now that I've got the files to do so, and I went into my apache configuration file, made a copy of the default ssl config in case I mess up, and went into nano to edit the apache ssl configuration, as follows:
1.) cd /etc/apache2/sites-available
2.) cp default-ssl.conf default-ssl.conf_backup
3.) sudo nano default-ssl.conf
Then I made sure that within this file, these parameters were set
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/nextcloud.martekservers.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.martekservers.com/privkey.pem
but I noticed when looking at apache documentation and when looking at the configuration of the file that I was editing, that there are "Server Certificate Chain" and "SSLCertificateChainFile." Are these created by certbot? Are these necessary for what I'm trying to do?
Note: I'm aware that they're using a different file type. ".pem" in my case, and ".crt" and ".ca-bundle" in theirs. Am I looking at the wrong documentation?
1 Like
Please use the actual Apache documentation and not some kind of incorrect and/or anchient blog.
(Although perhaps you should just read the "Note:" part after the example.)
Also, file extensions on Linux/Unix/*nix don't have the same value as extensions have on Windows systems.
4 Likes
However, there's no requirement that your domain registrar and DNS hosting provider need to be the same company.
This is true, though it's more convenient to have everything in one place, especially for an amateur.
Registrar based DNS hosting is typically pretty bottom-of-the-barrel in terms of reliability and the tools available to manage it.
Even after my short period of time in their control panel, I agree. There's not much in there other than the basics. I would definitely not recommend the way my predecessors went about setting up these domains.
I've spent a while looking now, and I'm still a bit confused. I tried using the search function on apache.org, which is that official site aforementioned, though I get responses on related projects, like tomcat.apache.org, and some others. Their site so far has been overall difficult to navigate for these sorts of questions. It's the reason I turned to other sources in the first place.
On a different note, to continue making progress, do you think that the amount that I had done within the config file was enough? Would I be able to enable HTTPS on the site after that?
Show the complete vhost config file.
2 Likes
The official site for the Apache webserver is https://httpd.apache.org/ and you can find its documentation here: Documentation: Apache HTTP Server - The Apache HTTP Server Project
3 Likes
Vhost file contents, shown from the aforementioned /etc/apache2/sites-available/default-ssl.conf
Before edits:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
# BrowserMatch "MSIE [2-6]" \
# nokeepalive ssl-unclean-shutdown \
# downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
After edits:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin {my email}
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/letsencrypt/live/nextcloud.martekservers.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.martekservers.com/privkey.pem
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
# BrowserMatch "MSIE [2-6]" \
# nokeepalive ssl-unclean-shutdown \
# downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Although is it the "_default_", I would still like to see:
ServerName example.com
ServerAlias www.example.com
[to match the name(s) on the certificate]
And use a real name for the file (not "default-ssl.conf").
2 Likes
I have the ServerName and ServerAlias written in my nextcloud conf file, so is it necessary to put them here?
I renamed the file to "nextcloud-ssl.conf"
Please show that entire file.
1 Like
The nextcloud conf file?
the part I was referring to was the section mentioning "trusted domains"
<?php
$CONFIG = array (
'instanceid' => (redacted)
'passwordsalt' => (redacted)
'secret' => (redacted)
'trusted_domains' =>
array (
0 => '192.168.1.38',
1 => 'nextcloud.martekservers.com',
),
'default_phone_region' => 'US',
'datadirectory' => '/var/www/nextcloud/data',
'dbtype' => 'mysql',
'version' => '23.0.0.10',
'overwrite.cli.url' => 'http://192.168.1.38',
'dbname' => 'nextcloud',
'dbhost' => 'localhost',
'dbport' => '',
'dbtableprefix' => 'oc_',
'mysql.utf8mb4' => true,
'dbuser' => '********',
'dbpassword' => '********',
'installed' => true,
'filelocking.enabled' => true,
'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 6379,
),
'app_install_overwrite' =>
array (
0 => 'documentserver_community',
),
'maintenance' => false,
);
Where are those lines?
3 Likes
They are shown in the file above, I had mistaken what I had put in the file as this.
Edit: by "above file", I mean the comment above yours, showing the file before and after edits.
I do not wish for this domain to be accessible off of my LAN, so may I exclude ServerAlias in the example you mentioned here?
Also, I relocated some the lines with the certificate file and the key file to the top of the file, as well as enabling encryption with what is shown after the DocumentRoot line.
ServerAdmin (my email)
ServerName nextcloud.martekservers.com
SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/nextcloud.martekservers.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.martekservers.com/privkey.pem
DocumentRoot /var/www/nextcloud
<Directory /var/www/nextcloud/>
Options FollowSymlinks
AlowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME /var/www/nextcloud
SetEnv HTTP_HOME /var/www/nextcloud
RewriteEngine On
RewriteRule ^/\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/host-meta https://%{SERVER_NAME}/public.php?service=host-meta [QSA,L]
RewriteRule ^/\.well-known/host-meta\.json https://%{SERVER_NAME}/public.php?service=host-meta-json [QSA,L]
RewriteRule ^/\.well-known/webfinger https://%{SERVER_NAME}/public.php?service=webfinger [QSA,L]
</Directory>
If that file listens on port 443, then you don't need the other "default" file (that also listens on port 443).
No sense in having two files listening on the same port trying to listen to the same name.
When that happens (bad), we call it a "name:port overlap" and must be corrected.
2 Likes
What do you mean by the "other 'default' file"?
The other file:
2 Likes