I have a WordPress site on LAMP stack. I got a SSL certificate using the certbot webroot method successfully. I looked at the certificate using “openssl x509 -noout -text -nameopt multiline -in fullchain.pem” and see the following information,
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
...
Signature Algorithm: sha256WithRSAEncryption
Issuer:
countryName = US
organizationName = Let's Encrypt
commonName = Let's Encrypt Authority X3
Validity
Not Before: ...
Not After : ...
Subject:
commonName = www.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
...
X509v3 Authority Key Identifier:
...
But I just can not get the site to respond to https request. When I try to access https://www.mydomain.com, the browser spins and eventually says the site can not be reached. The http access works fine.
I have the following in my httpd-vhost.conf file.
I turned apache LogLevel to debug and got the following information in logs/www.mydomain.com-ssl_error_log file. All these are from the “lampp restartapache” command. There is no more information added when I tried and failed to access https://www.mydomain.com. And there is nothing in the logs/www.mydomain.com-ssl_access_log file.
[Sat Jan 04 23:14:00.001264 2020] [ssl:info] [pid 38729] AH01914: Configuring server www.mydomain.com:443 for SSL protocol [Sat Jan 04 23:14:00.001479 2020] [ssl:debug] [pid 38729] ssl_engine_init.c(413): AH01893: Configuring TLS extension handling
[Sat Jan 04 23:14:00.001885 2020] [ssl:debug] [pid 38729] ssl_util_ssl.c(443): AH02412: [www.mydomain.com:443] Cert matches for name 'www.mydomain.com' [subject: CN=www.mydomain.com / issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US / serial: ... / notbefore: ... / notafter: ...]
[Sat Jan 04 23:14:00.001894 2020] [ssl:info] [pid 38729] AH02568: Certificate and private key www.mydomain.com:443:0 configured from /etc/letsencrypt/live/www.mydomain.com/fullchain.pem and /etc/letsencrypt/live/www.mydomain.com/privkey.pem
[Sat Jan 04 23:14:01.001224 2020] [ssl:info] [pid 38730] AH01914: Configuring server www.mydomain.com:443 for SSL protocol [Sat Jan 04 23:14:01.001430 2020] [ssl:debug] [pid 38730] ssl_engine_init.c(413): AH01893: Configuring TLS extension handling
[Sat Jan 04 23:14:01.001878 2020] [ssl:debug] [pid 38730] ssl_util_ssl.c(443): AH02412: [www.mydomain.com:443] Cert matches for name 'www.mydomain.com' [subject: CN=www.mydomain.com / issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US / serial: ... / notbefore: ... / notafter: ...]
[Sat Jan 04 23:14:01.001888 2020] [ssl:info] [pid 38730] AH02568: Certificate and private key www.mydomain.com:443:0 configured from /etc/letsencrypt/live/www.mydomain.com/fullchain.pem and /etc/letsencrypt/live/www.mydomain.com/privkey.pem
So what is happening? I can’t access my site through ssl but there is no message telling me what’s wrong. I greatly appreciate any advice. Thank you.
The ServerName for the :443 and :80 do not match.
You probably want both names in both vhost configs; like: ServerName www.mydomain.com ServerAlias mydomain.com
Using an FQDN:PORT in the VirtualHost definition is NOT good practice.
try using *:PORT instead; Like:
<VirtualHost *:443>
and
<VirtualHost *:80>
There is no error message produced. The error log is still the same now. The server doesn't have a firewall. Or if there is one I don't know about it. If a firewall blocks port 443, is there a way to find out?
Because the server is not secure (I know very little about security) and it is running something of importance, I am afraid of letting everyone know it is not secure. So I didn't share the domain name. Sorry.
This doesn't make much sense - unless the FQDNs are different IPs.
But even that sounds like a very low probability as the FQDN names are real Internet IPs.
So... please explain (with numbers and diagrams - if you have any) why you need to use the FQDN.
The :::port entries include all IPv6 and IPv4 IP addresses.
If you share your domain name, then it can be tested… instead of everyone playing a guessing game. Solutions can come a lot quicker if you had answered all of the questions when you first went to the help category.
I think my problem is because I don't know what I am doing.
I have three domains hosted on this one LAMP server. I put the following in my httpd-vhost.conf file.
I don't know how to avoid using FQDN:PORT.
BTW, these are all Wordpress sites. I wonder if Wordpress is playing some trick with the domain name because when I access www.mydomain.com it changes to mydomain.com in the browser. Also I wonder if LAMP or Wordpress is affecting the https operation. I just don't see any message about it.
Because I don't know much about security, having others test my site is the thing I am afraid of. I know there must be a thousand holes in my server security. Any competent hacker can break in and mess up my server. So I can't share the domain name. I will go back and look at other questions asked later today.
The tools being used test whether your ports are answering, if redirects are okay or wrong, if there is something wrong in your configuration (i.e.: using an IP address instead of your domain name in certain fields), whether you have created valid certificates but aren't using them, etc.. Many people can have their problems solved in just one to three posts unless they've made a mess of things. Your problem(s) can be solved a lot faster by showing your domain name. If you click on the Help topic in the categories list, look at the number of replies to the questions in the list. You'll see many with a low number of replies. Usually these are by people who immediately share their domain name. Those with higher numbers usually indicates those who didn't show their domain names until well into the conversation. It's kind of like asking a mechanic for help over the phone, but refusing to tell him what kind of vehicle you have.
It seems that what you are trying to do with FQDN:PORT is achieved by using unique SERVERNAME & SERVERALIAS within the configs.
[You don't need anything more than *:PORT in the VirtualHost definition.]
Each site should be specifically handled within the config that covers the sites name (using SERVERNAME and SERVERALIAS). Within that config you point to the particular document root for that name.
As an example: If you have 5 sites, you will still need 5 vhost configs [or maybe 10 if you have 80 and 443 for each name] (one for each and to be able to point them to their individual document roots).
BUT they will all have a similar VirtualHost *:port definitions.
[Note: Some may be *:80 and some may be *:443]
I went back and looked at the questions when starting a help topic and answered below. Hope this will provide some useful information for someone to help me. Thank you.
My domain is: Sorry I am not comfortable disclosing my domain name because it lets everyone know where a hacking target is. My server is definitely easily hackable.
I ran this command: https://www.mydomain.com
It produced this output: This site can't be reached.
My web server is (include version): LAMP 7.1.4-0
The operating system my web server runs on is (include version): CentOS Linux release 7.3.1611 (Core)
My hosting provider, if applicable, is: 1and1
I can login to a root shell on my machine (yes or no, or I don’t know): Yes.
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 1.0.0
That is a very false sense of security [for starters: everyone doesn't read through this forum].
Please understand:
a. If your server has an IPv4 address - it is known.
[scanners target every IPv4 address more than once per hour]
b. If your server has an open port - it is known.
[scans target even random IPv4 ports - so even "hiding" the port only provides a slight slowdown in detection and does nothing to stop hacks]
c. If your server is hackable - it is known.
[a scanner has "seen" it and is already being processed - as we speak - welcome to the Internet]
So...
Either:
Don't use IPv4 [use only IPv6, don't use common DNS names and only wildcard certs]
Don't open (hackable) ports [to unknown IPs]
Don't use hackable software [patch and secure your system(s)]
Although more is better, any one of those three steps would go a long way in preventing your system from being hacked.
[far more than NOT providing your domain name here]
What @rg305 says is correct. Do you realize it’s been 2 full days now and you’re still not at 1st base toward your solution? You could very well had your certificate installed and this all would have been in the past already. Internet security is a very concerning issue, but don’t let the fear of it keep you from getting the help you need to make your domain(s) secure. The decision is yours however and we’ll respect that… and will try to help if we can.
Thank you all for your patience and explanations. I really appreciate it.
I will read through the documentations @JimPas showed first. If I can’t make it work after that I will come back and provide my domain name and ask for more help.
