Www.grahamrmc.com

ok changed that I removed the 443 from the servername

went to my vhost.conf and added

<VirtualHost :80>
DocumentRoot /var/www/html
ServerName grmc-web.grahamrmc.com
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.
)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Things found in SSL.CONF
[not yet used in SSLVHOST.CONF]

Some are required to get SSL/TLS to work in a vhost...
Like:
SSLEngine on

I set sslvhost.conf and still had a problem

<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName www.grahamrmc.com
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
SSLHonorCipherOrder on
SSLCertificateFile /etc/letsencrypt/live/grahamrmc.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/grahamrmc.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/fullchain.pem

<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName grahamrmc.com
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
SSLHonorCipherOrder on
SSLCertificateFile /etc/letsencrypt/live/grahamrmc.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/grahamrmc.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/fullchain.pem

You can't use all three names in one vhost config.
Because they are not all covered by one cert.
You require two configs.

Unless their content will always be the same.
Then you can get one cert with all three names on it and use just one vhost config.

Stop using FULLCHAIN.pem
Please show:
grep -Eri 'chain' /etc/httpd/

[root@grmc-web ~]# grep -Eri 'chain' /etc/httpd/
/etc/httpd/conf.d/ssl.conf:# Server Certificate Chain:
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf:# certificate chain for the server certificate. Alternatively
/etc/httpd/conf.d/ssl.conf:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
/etc/httpd/conf.d/ssl.conf:SSLCertificateChainFile /etc/letsencrypt/live/grmc-web.grahamrmc.com/chain.pem
/etc/httpd/conf.d/ssl.conf:# issuer chain before deciding the certificate is not valid.
[root@grmc-web ~]#

That only shows the SSL.CONF file.
Where is the new file?

find / -name sslvhost.conf

sslvhost.conf

<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName www.grahamrmc.com
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
SSLHonorCipherOrder on
SSLCertificateFile /etc/letsencrypt/live/grahamrmc.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/grahamrmc.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/chain.pem

<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName grahamrmc.com
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
SSLHonorCipherOrder on
SSLCertificateFile /etc/letsencrypt/live/grahamrmc.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/grahamrmc.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/chain.pem

WHERE is it?
I see what is in it.
[which needs to be combined]
[you have the same thing twice]
[just use ServerName + ServerAlias to combine them]

But WHERE is the file?
find / -name sslvhost.conf

its in /etc/httpd/conf.d/sslvhost.conf

Why won’t the grep find it?
it found the /etc/https/ssl.conf file…
[and showed its’ contents]

please show:
ls -l /etc/httpd/conf.d/

[probably a permissions issue]
[should have run grep using sudo]

[root@grmc-web ~]# ls -l /etc/httpd/conf.d/
total 36
-rw-r--r--. 1 root root 2926 Nov 4 19:47 autoindex.conf
-rw-r--r--. 1 root root 1252 Jan 8 07:13 php.conf
-rw-r--r--. 1 root root 366 Nov 4 19:47 README
-rw-r--r--. 1 root root 10696 Feb 7 23:31 ssl.conf
-rw-r--r--. 1 root root 2646 Feb 7 23:44 sslvhost.conf
-rw-r--r--. 1 root root 1252 Oct 30 10:00 userdir.conf
-rw-r--r--. 1 root root 650 Feb 7 23:32 vhost.conf

That doesn’t add up.
Please show all output of:
sudo grep -Eri 'full|chain' /etc/httpd/conf.d/

[root@grmc-web ~]# sudo grep -Eri ‘full|chain’ /etc/httpd/conf.d/
/etc/httpd/conf.d/ssl.conf.backup:# Server Certificate Chain:
/etc/httpd/conf.d/ssl.conf.backup:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf.backup:# certificate chain for the server certificate. Alternatively
/etc/httpd/conf.d/ssl.conf.backup:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
/etc/httpd/conf.d/ssl.conf.backup:SSLCertificateChainFile /etc/letsencrypt/live/grmc-web.grahamrmc.com/chain.pem
/etc/httpd/conf.d/ssl.conf.backup:# issuer chain before deciding the certificate is not valid.
/etc/httpd/conf.d/ssl.conf:# Server Certificate Chain:
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf:# certificate chain for the server certificate. Alternatively
/etc/httpd/conf.d/ssl.conf:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
/etc/httpd/conf.d/ssl.conf:SSLCertificateChainFile /etc/letsencrypt/live/grmc-web.grahamrmc.com/chain.pem
/etc/httpd/conf.d/ssl.conf:# issuer chain before deciding the certificate is not valid.
/etc/httpd/conf.d/ssl.conf:# Server Certificate Chain:
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf:# certificate chain for the server certificate. Alternatively
/etc/httpd/conf.d/ssl.conf:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
/etc/httpd/conf.d/ssl.conf:SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/chain.pem
/etc/httpd/conf.d/ssl.conf:# issuer chain before deciding the certificate is not valid.
/etc/httpd/conf.d/ssl.conf:# Server Certificate Chain:
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf:# certificate chain for the server certificate. Alternatively
/etc/httpd/conf.d/ssl.conf:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
/etc/httpd/conf.d/ssl.conf:SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/chain.pem
/etc/httpd/conf.d/ssl.conf:# issuer chain before deciding the certificate is not valid.

That contradicts where you say you added SSL lines into SSLVHOST.CONF…

Please show:
cat /etc/httpd/conf.d/sslvhost.conf

I removed the sslvhost file then edited the ssl.conf file and the httpd server restarted…

When we also provide SSL we have to listen to the

the HTTPS port in addition.

Listen 443 https

SSL Global Context

All SSL configuration in this context applies both to

the main server and all SSL-enabled virtual hosts.

Pass Phrase Dialog:

Configure the pass phrase gathering process.

The filtering dialog program (`builtin’ is a internal

terminal dialog) has to provide the pass phrase on stdout.

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

Inter-Process Session Cache:

Configure the SSL Session Cache: First the mechanism

to use and second the expiring timeout (in seconds).

SSLSessionCache shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout 300

Pseudo Random Number Generator (PRNG):

Configure one or more sources to seed the PRNG of the

SSL library. The seed data should be of good random quality.

WARNING! On some platforms /dev/random blocks if not enough entropy

is available. This means you then cannot use the /dev/random device

because it would lead to very long connection times (as long as

it requires to make more entropy available). But usually those

platforms additionally provide a /dev/urandom device which doesn’t

block. So, if available, use this one instead. Read the mod_ssl User

Manual for more details.

SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512

Use “SSLCryptoDevice” to enable any supported hardware

accelerators. Use “openssl engine -v” to list supported

engine names. NOTE: If you enable an accelerator and the

server does not start, consult the error logs and ensure

your accelerator is functioning properly.

SSLCryptoDevice builtin
#SSLCryptoDevice ubsec

SSL Virtual Host Context

General setup for the virtual host, inherited from global configuration

DocumentRoot “/var/www/html”
ServerName grmc-web.grahamrmc.com

Use separate log files for the SSL virtual host; note that LogLevel

is not inherited from httpd.conf.

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSL Engine Switch:

Enable/Disable SSL for this virtual host.

SSLEngine on

SSL Protocol support:

List the enable protocol levels with which clients will be able to

connect. Disable SSLv2 access by default:

SSLProtocol all -SSLv2 -SSLv3

SSL Cipher Suite:

List the ciphers that the client is permitted to negotiate.

See the mod_ssl documentation for a complete list.

SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA >>>>orginial config here, adding new on next line

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Disable preloading HSTS in case of issues with CloadFlare

Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

Speed-optimized SSL Cipher configuration:

If speed is your main concern (on busy HTTPS servers e.g.),

you might want to force clients to specific, performance

optimized ciphers. In this case, prepend those ciphers

to the SSLCipherSuite list, and enable SSLHonorCipherOrder.

Caveat: by giving precedence to RC4-SHA and AES128-SHA

(as in the example below), most connections will no longer

have perfect forward secrecy - if the server’s key is

compromised, captures of past or future traffic must be

considered compromised, too.

#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
SSLHonorCipherOrder on

Server Certificate:

Point SSLCertificateFile at a PEM encoded certificate. If

the certificate is encrypted, then you will be prompted for a

pass phrase. Note that a kill -HUP will prompt again. A new

certificate can be generated using the genkey(1) command.

#SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateFile /etc/letsencrypt/live/grmc-web.grahamrmc.com/cert.pem

Server Private Key:

If the key is not combined with the certificate, use this

directive to point at the key file. Keep in mind that if

you’ve both a RSA and a DSA private key you can configure

both in parallel (to also allow the use of DSA ciphers, etc.)

#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/letsencrypt/live/grmc-web.grahamrmc.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/pki/tls/certs/server-chain.crt
SSLCertificateChainFile /etc/letsencrypt/live/grmc-web.grahamrmc.com/chain.pem

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)

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

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

Access Control:

With SSLRequire you can do per-directory access control based

on arbitrary complex boolean expressions containing server

variable checks and other lookup directives. The syntax is a

mixture between C and Perl. See the mod_ssl documentation

for more details.

#
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \

and %{SSL_CLIENT_S_DN_O} eq “Snake Oil, Ltd.” \

and %{SSL_CLIENT_S_DN_OU} in {“Staff”, “CA”, “Dev”} \

and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \

and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \

or %{REMOTE_ADDR} =~ m/^192.76.162.[0-9]+$/

#

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 StrictRequire:

This denies access when “SSLRequireSSL” or “SSLRequire” applied even

under a “Satisfy any” situation, i.e. when it applies access is denied

and no other module can change it.

o OptRenegotiate:

This enables optimized SSL connection renegotiation handling when SSL

directives are used in per-directory context.

#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ “.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars

<Directory “/var/www/cgi-bin”>
SSLOptions +StrictRequire

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-5]”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

Per-Server Logging:

The home of a custom SSL log file. Use this when you want a

compact non-error SSL logfile on a virtual host basis.

CustomLog logs/ssl_request_log
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x “%r” %b”

SSL Virtual Host Context

General setup for the virtual host, inherited from global configuration

DocumentRoot “/var/www/html”
ServerName www.grahamrmc.com

Use separate log files for the SSL virtual host; note that LogLevel

is not inherited from httpd.conf.

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSL Engine Switch:

Enable/Disable SSL for this virtual host.

SSLEngine on

SSL Protocol support:

List the enable protocol levels with which clients will be able to

connect. Disable SSLv2 access by default:

SSLProtocol all -SSLv2 -SSLv3

SSL Cipher Suite:

List the ciphers that the client is permitted to negotiate.

See the mod_ssl documentation for a complete list.

SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA >>>>orginial config here, adding new on next line

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Disable preloading HSTS in case of issues with CloadFlare

Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

Speed-optimized SSL Cipher configuration:

If speed is your main concern (on busy HTTPS servers e.g.),

you might want to force clients to specific, performance

optimized ciphers. In this case, prepend those ciphers

to the SSLCipherSuite list, and enable SSLHonorCipherOrder.

Caveat: by giving precedence to RC4-SHA and AES128-SHA

(as in the example below), most connections will no longer

have perfect forward secrecy - if the server’s key is

compromised, captures of past or future traffic must be

considered compromised, too.

#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
SSLHonorCipherOrder on

Server Certificate:

Point SSLCertificateFile at a PEM encoded certificate. If

the certificate is encrypted, then you will be prompted for a

pass phrase. Note that a kill -HUP will prompt again. A new

certificate can be generated using the genkey(1) command.

#SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateFile /etc/letsencrypt/live/grahamrmc.com/cert.pem

Server Private Key:

If the key is not combined with the certificate, use this

directive to point at the key file. Keep in mind that if

you’ve both a RSA and a DSA private key you can configure

both in parallel (to also allow the use of DSA ciphers, etc.)

#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/letsencrypt/live/grahamrmc.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/pki/tls/certs/server-chain.crt
SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/chain.pem

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)

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

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

Access Control:

With SSLRequire you can do per-directory access control based

on arbitrary complex boolean expressions containing server

variable checks and other lookup directives. The syntax is a

mixture between C and Perl. See the mod_ssl documentation

for more details.

#
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \

and %{SSL_CLIENT_S_DN_O} eq “Snake Oil, Ltd.” \

and %{SSL_CLIENT_S_DN_OU} in {“Staff”, “CA”, “Dev”} \

and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \

and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \

or %{REMOTE_ADDR} =~ m/^192.76.162.[0-9]+$/

#

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 StrictRequire:

This denies access when “SSLRequireSSL” or “SSLRequire” applied even

under a “Satisfy any” situation, i.e. when it applies access is denied

and no other module can change it.

o OptRenegotiate:

This enables optimized SSL connection renegotiation handling when SSL

directives are used in per-directory context.

#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ “.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars

<Directory “/var/www/cgi-bin”>
SSLOptions +StrictRequire

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-5]”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

Per-Server Logging:

The home of a custom SSL log file. Use this when you want a

compact non-error SSL logfile on a virtual host basis.

CustomLog logs/ssl_request_log
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x “%r” %b”

SSL Virtual Host Context

General setup for the virtual host, inherited from global configuration

DocumentRoot “/var/www/html”
ServerName grahamrmc.com

Use separate log files for the SSL virtual host; note that LogLevel

is not inherited from httpd.conf.

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSL Engine Switch:

Enable/Disable SSL for this virtual host.

SSLEngine on

SSL Protocol support:

List the enable protocol levels with which clients will be able to

connect. Disable SSLv2 access by default:

SSLProtocol all -SSLv2 -SSLv3

SSL Cipher Suite:

List the ciphers that the client is permitted to negotiate.

See the mod_ssl documentation for a complete list.

SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA >>>>orginial config here, adding new on next line

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Disable preloading HSTS in case of issues with CloadFlare

Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains”
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

Speed-optimized SSL Cipher configuration:

If speed is your main concern (on busy HTTPS servers e.g.),

you might want to force clients to specific, performance

optimized ciphers. In this case, prepend those ciphers

to the SSLCipherSuite list, and enable SSLHonorCipherOrder.

Caveat: by giving precedence to RC4-SHA and AES128-SHA

(as in the example below), most connections will no longer

have perfect forward secrecy - if the server’s key is

compromised, captures of past or future traffic must be

considered compromised, too.

#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
SSLHonorCipherOrder on

Server Certificate:

Point SSLCertificateFile at a PEM encoded certificate. If

the certificate is encrypted, then you will be prompted for a

pass phrase. Note that a kill -HUP will prompt again. A new

certificate can be generated using the genkey(1) command.

#SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateFile /etc/letsencrypt/live/grahamrmc.com/cert.pem

Server Private Key:

If the key is not combined with the certificate, use this

directive to point at the key file. Keep in mind that if

you’ve both a RSA and a DSA private key you can configure

both in parallel (to also allow the use of DSA ciphers, etc.)

#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/letsencrypt/live/grahamrmc.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/pki/tls/certs/server-chain.crt
SSLCertificateChainFile /etc/letsencrypt/live/grahamrmc.com/chain.pem

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)

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

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

Access Control:

With SSLRequire you can do per-directory access control based

on arbitrary complex boolean expressions containing server

variable checks and other lookup directives. The syntax is a

mixture between C and Perl. See the mod_ssl documentation

for more details.

#
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \

and %{SSL_CLIENT_S_DN_O} eq “Snake Oil, Ltd.” \

and %{SSL_CLIENT_S_DN_OU} in {“Staff”, “CA”, “Dev”} \

and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \

and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \

or %{REMOTE_ADDR} =~ m/^192.76.162.[0-9]+$/

#

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 StrictRequire:

This denies access when “SSLRequireSSL” or “SSLRequire” applied even

under a “Satisfy any” situation, i.e. when it applies access is denied

and no other module can change it.

o OptRenegotiate:

This enables optimized SSL connection renegotiation handling when SSL

directives are used in per-directory context.

#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ “.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars

<Directory “/var/www/cgi-bin”>
SSLOptions +StrictRequire

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-5]”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

Per-Server Logging:

The home of a custom SSL log file. Use this when you want a

compact non-error SSL logfile on a virtual host basis.

CustomLog logs/ssl_request_log
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x “%r” %b”

Where did this go?:

That did it. Now it works!

I put it in the ssl.conf file below the grmc-web.grahamrmc.com virtual host definition. Copied every then changed server name and certificate path…

Thanks for your time I really appreciate it!

1 Like