I've searched through help around here as much as I can, and still can't seem to be able to do the right things.
I'm trying to get my main domain using https (domain: keyorg.systems). It's apparently unable to find the right certificate, and instead uses a self-signed certificate (that I apparently just renewed using openssl). Apparently everytime I revoke, delete, and create a new certificate for my site it points to the self-signed cert instead of the cert that all of the other sites use.
All of my other domains on the server work with https, but the main one doesn't.
I'm running a centos7 + Apache2.4.6 + certbot 1.4.0
I seem to have three certbot accounts (ls -lah /etc/letsencrypt/accounts:
staging-v02 (which I think is the self-signed)
acme-v1
acme v2
I have a few domains (there are more but i don't want to bore you)
blah.blah
other.other
when I run httpd -S I see:
default server blah.blah (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost blah.blah (/etc/httpd/sites-available/blah.blah-le-ssl.conf:2)
any help appreciated
tl;dr
I don't know what to delete to get rid of a self-signed certificate so I can get the nice cool lock that my other sites have
I can't seem to make the default server point to the right conf file (do I put 'vhost: 443' it in the first vhost, or put the block in ssl.conf
Please share your entire httpd -S output (I think you can remove the "blah.bla" and "other.other" domains if you'd like) and also the entire command you've used to get the certificate.
Also note that issuing -> deleting -> issuing -> deleting -> issuing certificates is NOT the correct way to fix installation issues: if you got the certificate issued, you have reached the installation part of the whole process: issuing and installation are SEPARATE entities, so issuing new certs over and over will NOT help installing it. It will only add more and more load upon the Let's Encrypt systems and will risk you running into rate limits. Please refrain from issuing multiple certificates if it's an installation problem.
the command I used to get the certs is simply "certbot" and then chose the # of the domain I wanted.
I will refrain from re-issuing certs. I get the difference intellectually, but don't know what commands to use to install the issued certs (esp as i didn't manually install the other certs)
here's the output:
*:80 is a NameVirtualHost
default server www.000-default.keyorg.systems (/etc/httpd/conf.d/000-default.conf:1)
port 80 namevhost www.000-default.keyorg.systems (/etc/httpd/conf.d/000-default.conf:1)
*:443 is a NameVirtualHost
default server keyorg.systems (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost keyorg.systems (/etc/httpd/conf.d/ssl.conf:56)
...
port 443 namevhost subdomain.blah.blah (/etc/httpd/sites-available/subdomain.blah.blah-le-ssl.conf:2)
port 443 namevhost keyorg.systems (/etc/httpd/sites-available/keyorg.systems-le-ssl.conf:2)
it may help that I think i changed my FQDN or hostname between the issuance of the first cert for blah.blah and now. I think the previous was look for centos-ny1-digita-locean or whatever they called it vs the subdomain.domain.tld that it uses now.
Thanks in advance for your assistance. and let me know if I've missed including anything you need
Your hostname keyorg.systems has two namevhosts in two different configuration files. The latter (with the le-ssl.conf ending) was generated by certbot, but I think your Apache is using the former namevhost from ssl.conf. It probably has the self signed certificate from that configuration file. I recommend to combine the keyorg.systems HTTPS virtualhost (namevhost) from ssl.conf and the keyorg.systems HTTPS virtualhost from keyorg.systems-le-ssl.conf into a single file, preferably a separate file like keyorg.systems-le-ssl.conf.
I'm guessing keyorg.systems-le-ssl.conf already has the correct certificates configured, so unless the virtualhost in ssl.conf has options which are not in keyorg.systems-le-ssl.conf, it should suffice to disable the keyorg.systems HTTPS virtualhost in ssl.conf. If there are important options in that ssl.conf virtualhost, you can migrate them to keyorg.systems-le-ssl.conf.
Afterwards, I would suggest to run certbot again and when it asks you to Re-issue or to attempt to install it again, select the "attempt to install it again" option and see what happens.
Also, if it doesn't work, please output the certbot output too.
Here's the rub. There's no config information in /etc/httpd/conf.d/ssl.conf that points to keyorg.systems. the command: grep -ir keyo ssl.conf
comes up empty!
and as for changing what ssl.conf aims at, an earlier stage in my troubleshooting I pointed the SSLCertificate___ to the certs relating to keyorg.systems instead of the default /etc/pki/tls/___etc - that's all in a backup file.
I think you're spot on that the server is using the default server (first). I don't know how to disable it and make it use the second vhost without disabling ssl.conf (which borks the server).
I tried to specify keyorg.systems on line 56 (Vhost) and 60 (ServerName) to no avail.
anyhoo... here's the output of re-running certbot:
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 12
Cert not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/keyorg.systems.conf)
What would you like to do?
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Keeping the existing certificate
Deploying Certificate to VirtualHost /etc/httpd/sites-available/keyorg.systems-le-ssl.conf
Redirecting vhost in /etc/httpd/conf.d/keyorg.systems.conf to ssl vhost in /etc/httpd/sites-available/keyorg.systems-le-ssl.conf
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/keyorg.systems/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/keyorg.systems/privkey.pem
Your cert will expire on 2021-03-05. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew all of
your certificates, run "certbot renew"
Could you give the contents of ssl.conf? It's rather strange that it would be used as that namevhost while there already is another configuration file for it.. Perhaps we're missing something in the files contents.
Please put three backticks (```) above and below the contents so it will get formatted properly.
Note: the backticks are a different symbol than single quotes. The backticks are just left of the "1" on your keyboard if you have the US layout. You can also copy/paste the backticks from my post
I'm not seeing any ServerName in there, so I assume Apache is guessing the hostname by other means, such as "Asking the OS" as stated in the Apache ServerName documentation.
I recommend forcing the default <VirtualHost> in ssl.conf to a different hostname altogether. In my Apaches default ssl configuration (Gentoo) it seems it has ServerName localhost. That would force Apache to use your ...le-ssl.conf for the appropriate namevhost and would solve your issue.
I did find when I changed SErverName to keyorg.systems the default servername changed to a different server ... and then that ssl https://otherdomain.com failed. I think what I need to do is create a subdomain as default server, force it to use that and let that fail all it wants to liberate my main domain. it's a hack, but it may just get me out of this hole.
anyhow, here's the stuff with the right backticks:
cat ssl.conf
#
# 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
##
<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
# 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
# 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
# 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
# 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
# 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.
#<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
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<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 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"
</VirtualHost>
so it's fixed. while switching between subdomains and whatnot, I noticed that it's reading from the first item in /etc/httpd/conf/http.conf
All I had to do (hours of drudging and months of frustration mind you -and thanks for your help) was to move the default domain keyorg.systems to the top of the list.
wow.
I really appreciate all the help, time, care, and attention you've spent/donated with me.
*:443 is a NameVirtualHost
default server keyorg.systems (/etc/httpd/sites-available/keyorg.systems-le-ssl.conf:2)
port 443 namevhost keyorg.systems (/etc/httpd/sites-available/keyorg.systems-le-ssl.conf:2)
alias www.keyorg.systems```
