Https doesnt work after ip change


#1

Hi

Resently i have changed my network and my webserver is now running behind firewall and has different ip (server had external ip address and now it has local ip adress) web ports 80 443 are open to this ip, http is working fine but https doesnt. Could the problem be in certbot or evrything should work fine and i have to do something with my firewall?
Thank you!

My domain is:kjtg.edu.ee
I ran this command:certbot certonly --manual -d kjtg.edu.ee
The operating system my web server runs on is (include version):Ubuntu server 14.04
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


#2

Hi,

Does your website (server) now can’t be accessed from external network? Or you’ll need to configure your firewall to allow incoming connection?

If this(can’t connect to network) is the case, you can’t get a certificate from Let’s Encrypt using HTTP-01 (basically, connects to your website and verify if there’s a correct challenge file that existed in the specified path). But you still could use DNS-01 validation (adding DNS txt records to proof ownership).

BTW: I tried to connect to the domain, and there’s an empty page.

Did you get any error message?

Thank you


#3

Thanks for quick reply!
Yes it can be accessed http works fine for example kjtg.edu.ee/gallery works
https://kjtg.edu.ee/moodle doesnt work. 443 port is open
Had no error message with certbot certonly --manual -d kjtg.edu.ee


#4

The problem is probably that while you have setup port forwarding on port 443, it’s pointing to your internal port 80, rather than to internal 443.

This can be demonstrated by making a plaintext request on the SSL port.

$ curl -i http://kjtg.edu.ee:443/moodle/
HTTP/1.1 303 See Other
Date: Tue, 11 Dec 2018 07:27:53 GMT
Server: Apache/2.4.7 (Ubuntu)
Location: https://kjtg.edu.ee/moodle
Content-Language: ru
Content-Length: 591
Content-Type: text/html; charset=UTF-8

Making such a request should either fail entirely (for protocol reasons), or give an HTTP 400 Bad Request.

If you are not using any port forwarding, then the issue is probably that your port 443 VirtualHost in Apache is not actually configured for HTTPS.


#5

Using certonly doesn’t make any web server modifications to use the cert.
It literally only gets the cert.


#6

Exactly im using port forward on my firewall now. port 443 VirtualHost in Apache is actually configured for HTTPS. And it worked before firewall.

Witch command fully upgrades my cert?


#7

Can you take a screenshot of your port forwarding rules? Because it seems like you’re forwarding external 443->internal 80.

Also, try run from your Apache server (locally):

openssl s_client -connect localhost:443 -showcerts | openssl x509 -noout -subject

(edit -subject not -subj)


#8

This one? Im sure about my firewall setup because i didnt set up it my self :grin:
Capture
Some kind of error

openssl s_client -connect localhost:443 -showcerts | openssl x509 -noout -subject
140025888802624:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:…/ssl/record/ssl3_record.c:252:
unable to load certificate
140162367383360:error:0906D06C:PEM routines:PEM_read_bio:no start line:…/crypto/pem/pem_lib.c:691:Expecting: TRUSTED CERTIFICATE


#9

OK. That openssl error shows that your Apache server is not talking HTTPS over port 443:

Can you show the configuration your port 443 VirtualHost fully?


#10

First, let’s see which certificates you have.
Please show:
certbot --version
certbot certificates

Then we can see how to use them in your web server configuration.

[edit]
http://kjtg.edu.ee:80/ and http://kjtg.edu.ee:443/ return the same content.


#11

i have this


this configuration of port 443 VirtualHost

ServerAdmin webmaster@localhost DocumentRoot /var/www/ ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/letsencrypt/live/kjtg.edu.ee/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/kjtg.edu.ee/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ServerName k
SSLCertificateChainFile /etc/letsencrypt/live/kjtg.edu.ee/chain.pem
</VirtualHost>
</IfModule>

certbot --version
certbot 0.17.0

certbot certificates

Found the following certs:
Certificate Name: kjtg.edu.ee-0006
Domains: kjtg.edu.ee
Expiry Date: 2019-02-06 09:29:24+00:00 (VALID: 57 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee-0006/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee-0006/privkey.pem
Certificate Name: kjtg.edu.ee-0002
Domains: kjtg.edu.ee
Expiry Date: 2019-02-05 21:20:09+00:00 (VALID: 56 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee-0002/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee-0002/privkey.pem
Certificate Name: kjtg.edu.ee-0007
Domains: kjtg.edu.ee
Expiry Date: 2019-03-09 09:51:01+00:00 (VALID: 88 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee-0007/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee-0007/privkey.pem
Certificate Name: kjtg.edu.ee-0005
Domains: kjtg.edu.ee
Expiry Date: 2019-02-05 09:13:23+00:00 (VALID: 55 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee-0005/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee-0005/privkey.pem
Certificate Name: kjtg.edu.ee-0003
Domains: kjtg.edu.ee
Expiry Date: 2019-02-05 21:20:14+00:00 (VALID: 56 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee-0003/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee-0003/privkey.pem
Certificate Name: kjtg.edu.ee-0004
Domains: kjtg.edu.ee
Expiry Date: 2019-02-06 09:29:30+00:00 (VALID: 57 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee-0004/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee-0004/privkey.pem
Certificate Name: kjtg.edu.ee-0001
Domains: kjtg.edu.ee
Expiry Date: 2019-03-08 09:39:28+00:00 (VALID: 87 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee-0001/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee-0001/privkey.pem
Certificate Name: kjtg.edu.ee
Domains: kjtg.edu.ee
Expiry Date: 2019-03-11 05:40:48+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/kjtg.edu.ee/fullchain.pem
Private Key Path: /etc/letsencrypt/live/kjtg.edu.ee/privkey.pem

dunno why so many


#12

That should match the cert:
ServerName kjtg.edu.ee

Certbot version is somewhat outdated.

Seems your renewal process is forcing a new cert before it is needed.
You should use the latest one (with most amount of days left):


#13

It does seem that you are using the latest cert, but the name doesn’t match the cert:


#14

Now I can see why that is happening.
You only have three configs:
One is port 80 only (won’t match :443)
One is port 443 only (won’t match server name to cert)
One is all ports - so this one is forced to match - but has no way to encrypt connections.


#15

Can you include the line that goes:

<VirtualHost *:443>

It can have a material difference as to whether the server will respond with HTTPS or not.

e.g. If you did anything resembling this:

<VirtualHost kjte.edu.ee:443>

It’s likely to explain your problems. Try with * instead. You should be using name-based virtualhosts, not address-based anyway.


#16

I dont know how it worked before then…
I did update

i change server name

And did that too

did apache restart
AND IT WORKED!! Moodle working again, students are login in-)
Thank you all very much=)


#17

We need to review your command and setup the renew correctly.
So far, it seems you have been generating certs even when it wasn’t even close to expire.


#18

i have this in cron :thinking: shoud i change it?

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew

#19

That is the preferred way.
I’m glad that worked for you :slight_smile:


#20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.