On Mon, Nov 27, 2023 at 2:47 PM John <john.ili...@iliffe.ca> wrote:
> On Sun, 2023-11-26 at 18:06 -0500, Paul wrote: > > On 2023-11-26 16:12, John wrote: > > > After a week of chasing this around I have managed to change the > problem several times but I'm > > > still > > > unable to get Apache started. I **think** there is something > unrelated to the error that I'm > > > seeing > > > that may have been included in the default config but before I go down > that rabbit hole I > > > realize > > > that I am making a number of assumptions because I don't know how to > check, so if everyone would > > > please bear with me, and my apologies in advance: > > > > > > Here are the relevant parts of the full configuration: > > > > > > /usr/sbin/httpd -M > > > > I think you said you were using "Rocky Linux" associated with RHEL which > > may use /usr/sbin/httpd rather than /usr/share/apache2 (debian). If > > "Rocky" is a spin-off (I have no knowledge of it) perhaps they have a > > "users list" that could help you? > > > > In any case what is the output of 'apachectl -S' (or perhaps 'httpd > > -S')? Is it only your TLS that is problematic, or are there other > > underlying glitches? You write "httpd.service: Main process exited, > > code=exited, status=1/FAILURE" and this looks to me that it could > > preceed any TLS certs. > > > > Also, your "SSLCACertificateFile" probably has to be used carefully. It > > "can be used alternatively and/or additionally to "SSLCACertificatePath" > > and should only be used if "SSLCADNRequestPath or SSLCADNRequestFile" > > are missing. See <https://httpd.apache.org/docs/2.4/mod/mod_ssl.html>. > > Yours appear to be missing from what you write (please delete all rem'ed > > out lines, it's rather boring) - are you sure this is what you want? > > > > Good luck -- Paul > > > > > > ***89 deleted module lines here** > > > ssl_module (shared) > > > systemd_module (shared) > > > > > > the full config file for the ONLY https virtual server > > > ------ > > > # SSL Support for Coax Publications ONLY! > > > <Virtualhost *:443> > > > ServerName www.coaxpublications.ca > > > # ServerAlias t.coaxpublications.ca > > > DocumentRoot /usr/httpd/coax > > > Options -MultiViews > > > H2Direct on > > > ProxyPassMatch "^/.*\.php(/.*)?$" fcgi:// > 127.0.0.1:9002/usr/httpd/coax > > > SSLEngine on > > > # SSLCipherSuite HIGH: !ADH: !SSLv2: !SSLv3: !TLSv1: !RC4: !PSK: !MD5 > > > SSLCipherSuite TLSv1.3 > > > SSLCertificateFile > /etc/httpd/conf/sslcert/www.coaxpublications.ca.pem > > > SSLCertificateKeyFile > /etc/httpd/conf/sslcert/www.coaxpublications.ca.key > > > SSLCACertificateFile /etc/httpd/conf/sslcert/intermediate.crt > > > SSLHonorCipherOrder on > > > Header always set Strict-Transport-Security > "max-age-63072000;includeSubDomains" > > > </VirtualHost> > > > > > > # Redirect if logon is to coaxpublications without the 'www' > > > <VirtualHost *:80> > > > ServerName coaxpublications.ca > > > Redirect permanent / https://www.coaxpublications.ca > > > </VirtualHost> > > > ------ > > > > > > the systemctl status on attempting to start: > > > ------ > > > # systemctl status httpd > > > × httpd.service - The Apache HTTP Server > > > Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; > preset: disabled) > > > Drop-In: /usr/lib/systemd/system/httpd.service.d > > > └─php-fpm.conf > > > Active: failed (Result: exit-code) since Sun 2023-11-26 15:14:50 > EST; 25min ago > > > Duration: 1d 22h 32min 36.626s > > > Docs: man:httpd.service(8) > > > Process: 56733 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND > (code=exited, > > > status=1/FAILURE) > > > Main PID: 56733 (code=exited, status=1/FAILURE) > > > Status: "Reading configuration..." > > > CPU: 25ms > > > > > > Nov 26 15:14:50 prod02 systemd[1]: Starting The Apache HTTP Server... > > > Nov 26 15:14:50 prod02 systemd[1]: httpd.service: Main process exited, > code=exited, > > > status=1/FAILURE > > > Nov 26 15:14:50 prod02 systemd[1]: httpd.service: Failed with result > 'exit-code'. > > > Nov 26 15:14:50 prod02 systemd[1]: Failed to start The Apache HTTP > Server. > > > ------ > > > > > > our production TLS certificate. The one on the problem server is a > .pem version of the same > > > thing > > > because it will eventually replace this server. What I don't know is > how to confirm that the > > > .pem > > > cert is identical to this one. > > > > > > ------ > > > <!-- This Source Code Form is subject to the terms of the Mozilla > Public > > > - License, v. 2.0. If a copy of the MPL was not distributed with > this > > > - file, You can obtain one at http://mozilla.org/MPL/2.0/. --> > > > <!DOCTYPE html> > > > <html lang="en-US" dir="ltr"><head> > > > <meta http-equiv="content-type" content="text/html; charset=UTF-8"> > > > <meta name="viewport" content="width=device-width"> > > > <meta http-equiv="Content-Security-Policy" content="default-src > chrome:; object-src > > > 'none'"> > > > <meta name="color-scheme" content="light dark"> > > > <link rel="localization" href="toolkit/about/certviewer.ftl"> > > > <link rel="localization" href="branding/brand.ftl"> > > > <script type="module" > src="chrome://global/content/certviewer/certviewer.mjs"></script> > > > <script type="module" > src="chrome://global/content/certviewer/components/certificate- > > > section.mjs"></script> > > > <script type="module" > src="chrome://global/content/certviewer/components/about-certificate- > > > section.mjs"></script> > > > <link rel="stylesheet" > href="chrome://global/skin/in-content/common.css"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/certviewer.css"> > > > <title id="certTitle" data-l10n- > > > args="{"firstCertName":"www.coaxpublications.ca"}" > data-l10n- > > > id="certificate- > > > viewer-tab-title">Certificate for www.coaxpublications.ca</title> > > > </head> > > > <body> > > > <template id="certificate-section-template" class="section"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/components/certificate- > > > section.css"> > > > <h1 class="title"></h1> > > > </template> > > > > > > <template id="certificate-tabs-template"> > > > <div class="certificate-tabs" role="tablist"></div> > > > </template> > > > > > > <template id="info-groups-template"> </template> > > > > > > <template id="info-item-template"> > > > <link rel="stylesheet" > href="chrome://global/skin/in-content/common.css"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/components/info- > > > item.css"> > > > <label></label> > > > <span class="info"></span> > > > </template> > > > > > > <template id="info-group-template"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/components/info- > > > group.css"> > > > <span class="extension"> > > > <img src="chrome://global/skin/icons/error.svg" > id="critical-info" data-l10n- > > > id="certificate-viewer-critical-extension"> > > > <h2 class="info-group-title"></h2> > > > </span> > > > <span class="info-group-title-hr"></span> > > > </template> > > > > > > <template id="error-section-template"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/components/error- > > > section.css"> > > > <h1 class="title"></h1> > > > <span class="error"></span> > > > </template> > > > > > > <template id="about-certificate-template" class="section"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/components/certificate- > > > section.css"> > > > <h1 class="title"></h1> > > > </template> > > > > > > <template id="about-certificate-items-template"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/components/about- > > > certificate- > > > section.css"> > > > </template> > > > > > > <template id="list-item-template"> > > > <link rel="stylesheet" > href="chrome://global/content/certviewer/components/list- > > > item.css"> > > > <a class="cert-url"><span class="item-name"></span></a> > > > <button class="export"></button> > > > </template> > > > > > > > > > <certificate-section></certificate-section></body></html> > > > ------ > > > > > > the error log for mod_ssl > > > > > > ------ > > > Sun Nov 26 15:14:50.745976 2023] [ssl:warn] [pid 56733:tid 56733] > AH01909: www.iliffe.ca:443:0 > > > server certificate does NOT include an ID which matches the server name > > > ------ > > > Now here is where I get really confused: there is NO config file for > virtual server iliffe.ca > > > that > > > makes it an HTTPS server. It is simply our test server and runs as > http on port 80. The only > > > possible reason that I can think of why this should have been included > in the https chain as > > > needing > > > a certificate is the default Rocky ssl.conf file that gets > automatically inserted (include > > > *.conf) > > > at startup and comes with the 'dnf install mod_ssl'. Here it is in > full, fortunately it is > > > mostly > > > comments: > > > ------ > > > # > > > # When we also provide SSL we have to listen to the > > > # standard 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 > > > > > > # > > > # 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 > > > ## > > > > > > <VirtualHost _default_:443> > > > > > > # General setup for the virtual host, inherited from global > configuration > > > #DocumentRoot "/var/www/html" > > > #ServerName www.example.com:443 > > > > > > # 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 > > > > > > # List the protocol versions which clients are allowed to connect > with. > > > # The OpenSSL system profile is used by default. See > > > # update-crypto-policies(8) for more details. > > > #SSLProtocol all -SSLv3 > > > #SSLProxyProtocol all -SSLv3 > > > > > > # User agents such as web browsers are not configured for the user's > > > # own preference of either security or performance, therefore this > > > # must be the prerogative of the web server administrator who manages > > > # cpu load versus confidentiality, so enforce the server's cipher > order. > > > SSLHonorCipherOrder on > > > > > > # SSL Cipher Suite: > > > # L# See the mod_ssl documentation for a complete list. > > > # The OpenSSL system profile is configured by default. See > > > # update-crypto-policies(8) for more details. > > > SSLCipherSuite PROFILE=SYSTEM > > > SSLProxyCipherSuite PROFILE=SYSTEM > > > > > > # Point SSLCertificateFile at a PEM encoded certificate. If > > > # the certificate is encrypted, then you will be prompted for a > > > # pass phrase. Note that restarting httpd will prompt again. Keep > > > # in mind that if you have both an RSA and a DSA certificate you > > > # can configure both in parallel (to also allow the use of DSA > > > # ciphers, etc.) > > > # Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt) > > > # require an ECC certificate which can also be configured in > > > # parallel. > > > # SSLCertificateFile /etc/pki/tls/certs/localhost.crt <---original > > > SSLCertificateFile /etc/httpd/conf/sslcert/www.coaxpublications.ca.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 > > > > > > > > > # 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.) > > > # ECC keys, when in use, can also be configured in parallel > > > # SSLCertificateKeyFile /etc/pki/tls/private/localhost.key > <---original > > > SSLCertificateKeyFile > /etc/httpd/conf/sslcert/www.coaxpublications.ca.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 convenience. > > > #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.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) > > > #SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt <---original > > > SSLCACertificateFile /etc/httpd/conf/sslcert/intermediate.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. > > > #<Location /> > > > #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]+$/ > > > #</Location> > > > > > > # 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 > > > <FilesMatch "\.(cgi|shtml|phtml|php)$"> > > > SSLOptions +StdEnvVars > > > </FilesMatch> > > > <Directory "/var/www/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 sent or allowed to be 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 sent 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" > > > > > > </VirtualHost> > > > ------ > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2023-11-21 at 19:01 -0800, Aditya Shastri wrote: > > > > To answer your question to the best of my knowledge, > > > > 1. Openssl 1.1.1 and above support TLSv1.3. These are the TLSv1.3 > > > > ciphers Openssl 3.0 support > > > > > https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_ciphersuites.html > > > > 2. This link says that TLSv1.3 is supported. > > > > > https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite:~:text=If%20the%20SSL%20library%20supports%20TLSv1.3 > > > > > > > > Can you give us the output of > > > > $ openssl ciphers -s -v -tls1_3 > > > > > > > > One option to test the ciphers on your HTTPD is to change the > > > > SSLCipherSuite to allow all ciphers and use a tool like > > > > https://testssl.sh/ to list all the ciphers available to help > > > > troubleshoot further. > > > > > > > > On Tue, Nov 21, 2023 at 12:37 PM John <john.ili...@iliffe.ca> wrote: > > > > > > > > > > Apache won't start when https/TLS is activated although it runs > fine with only http. I made > > > > > the > > > > > changes previously suggested but now httpd just doesn't start. > The error from systemctl is: > > > > > ----- > > > > > Nov 21 15:17:51 prod02 systemd[1]: Starting The Apache HTTP > Server... > > > > > Nov 21 15:17:51 prod02 systemd[1]: httpd.service: Main process > exited, code=exited, > > > > > status=1/FAILURE > > > > > Nov 21 15:17:51 prod02 systemd[1]: httpd.service: Failed with > result 'exit-code'. > > > > > Nov 21 15:17:51 prod02 systemd[1]: Failed to start The Apache HTTP > Server. > > > > > ----- > > > > > and a more useful error from the Apache error log is: > > > > > ----- > > > > > [Tue Nov 21 15:17:51.411388 2023] [core:notice] [pid 29577:tid > 29577] SELinux policy > > > > > enabled; > > > > > httpd > > > > > running as context system_u:system_r:httpd_t:s0 > > > > > [Tue Nov 21 15:17:51.412008 2023] [suexec:notice] [pid 29577:tid > 29577] AH01232: suEXEC > > > > > mechanism > > > > > enabled (wrapper: /usr/sbin/suexec) > > > > > [Tue Nov 21 15:17:51.415738 2023] [ssl:emerg] [pid 29577:tid > 29577] AH01898: Unable to > > > > > configure > > > > > permitted SSL ciphers > > > > > [Tue Nov 21 15:17:51.415748 2023] [ssl:emerg] [pid 29577:tid > 29577] SSL Library Error: > > > > > error:0A0000B9:SSL routines::no cipher match > > > > > [Tue Nov 21 15:17:51.415751 2023] [ssl:emerg] [pid 29577:tid > 29577] AH02312: Fatal error > > > > > initialising mod_ssl, exiting. > > > > > AH00016: Configuration Failed > > > > > ---- > > > > > I **think** this may be due to the fact that the default > installation of Rocky has a lot of > > > > > http > > > > > config files and they all get concatenated BUT I haven't been able > to figure out the > > > > > SSLCipherSuite > > > > > line. ssl.conf (default install) has this: > > > > > #SSLCipherSuite PROFILE=SYSTEM > > > > > SSLProxyCipherSuite PROFILE=SYSTEM > > > > > but I can't find "SYSTEM" in any of Apache, OpenSSL, or Rocky docs > and it isn't defined in > > > > > this > > > > > configuratiion file. > > > > > Also included in the concatenation is the custom one for this > server: > > > > > # SSLCipherSuite HIGH: !ADH: !SSLv2: !SSLv3: !TLSv1: !RC4: !PSK: > !MD5 > > > > > SSLCipherSuite TLSv1.3 > > > > > The first line is copied from the old (current production) server > and leads to a failure to > > > > > start > > > > > error in the syntax immediately but best practice suggests that > the second line is what I > > > > > want > > > > > anyway. Reading up on this suggests that the '!' ciphers do not > appear in TLSv1.3 so not > > > > > available > > > > > to delete. > > > > > > > > > > The docs indicate that SSLCipherSuite is a per directory parameter > and no conflict should be > > > > > caused > > > > > by it appearing in two different files. > > > > > > > > > > So, I have two immediate questions: > > > > > 1. I have the default openssl installed which is version > openssl-3.0.7-6.el9_2.x86_64. > > > > > Is > > > > > this adequate to provide all ciphers that are required by the > cipher suite TLSv1.3? > > > > > 2. Is there something that someone knows of by way of > documentation that I haven't > > > > > found > > > > > yet? > > > > > > > > > > Thanks for any assistance. > > > > > > > > > > John > > > > > ====== > > > > > > This should reply to both Paul and Frank: > > First, yes, sorry about including all those commented lines but I wanted > you to see the .conf files > as I encountered them in case there was an error in the instructions or my > implementation of them. > > httpd -S > VirtualHost configuration: > *:80 is a NameVirtualHost > default server coaxpublications.ca > (/etc/httpd/conf.d/coax.conf:22) > port 80 namevhost coaxpublications.ca > (/etc/httpd/conf.d/coax.conf:22) > port 80 namevhost www.iliffe.ca > (/etc/httpd/conf.d/iliffe.conf:13) > port 80 namevhost t_iliffe.ca (/etc/httpd/conf.d/iliffe.conf:23) > *:443 is a NameVirtualHost > default server www.coaxpublications.ca > (/etc/httpd/conf.d/coax.conf:4) > port 443 namevhost www.coaxpublications.ca > (/etc/httpd/conf.d/coax.conf:4) > port 443 namevhost www.iliffe.ca (/etc/httpd/conf.d/ssl.conf:40) > ServerRoot: "/etc/httpd" > Main DocumentRoot: "/var/www/html" > Main ErrorLog: "/var/log/httpd/error.log" > Mutex authdigest-client: using_defaults > Mutex lua-ivm-shm: using_defaults > Mutex ssl-stapling: using_defaults > Mutex proxy: using_defaults > Mutex authn-socache: using_defaults > Mutex ssl-cache: using_defaults > Mutex default: dir="/etc/httpd/run/" mechanism=default > Mutex cache-socache: using_defaults > Mutex authdigest-opaque: using_defaults > Mutex watchdog-callback: using_defaults > Mutex proxy-balancer-shm: using_defaults > Mutex rewrite-map: using_defaults > Mutex ssl-stapling-refresh: using_defaults > PidFile: "/etc/httpd/run/httpd.pid" > Define: DUMP_VHOSTS > Define: DUMP_RUN_CFG > User: name="apache" id=48 > Group: name="apache" id=48 > > This might give an indication of why it thinks iliffe.ca, the test > server, should have a > certificate, apparently it is inherited from ssl.conf > (/etc/httpd/conf.d/ssl.conf:40). This server > is entirely internal here and will never have a certificate since it is > only used for testing. > Would I be correct in thinking that ssl.conf should be deleted and > relevant lines included in the > proper https virtual server contexts? > > Second, neither of SSLCADNRequestFile or SSLCADNRequestPath are defined > anywhere in the .conf files. > I am using the default ssl.conf file since the configuration that arises > when you do a "dnf install > httpd" on Rocky is very much different from what I have on the old (Fedora > 16 was the base) server. > On that one I installed Apache from source. > > The "intermediate.crt" file turned up about 5 years ago when I renewed the > certificate and I was > lead to believe is required to validate the CA that signed the server > certificate. Reading the > current docs suggests that I meed a .pem encoded certificate here but the > suffix suggests this is in > .crt format. I do have another certificate that turned up recently (2021 > renewal probably) called > www-coaxpublications-ca-chain.pem. It isn't in use on the current server > but would this be the one > I need here? If so, would this be the target of the SSLCACertificatePath > directive? > > To Paul: Rocky Linux is one of the replacements for CentOS and is supplied > by CIQ as a FOSS > download. The version I'm using, 9.1, should be more or less equivalent > to RHEL 9.1, in any event > it is a derivative of RHEL. > > Finally, thank you to both of you - this conversion has been one of the > more frustrating things I > have encountered lately. > > John > ======= > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > When you create TLS vhosts, you have to make sure that the common name in the certificate file will match the ServerName set in the vhost; this is how you get rid of that warning. If you have to, use a self-signed certificate for that vhost. You likely don't need intermediate certificates, the chain is included in most certificate files nowadays. You can verify with openssl.
