Enable HTTPS Best Recommended

Daedalus01

I am wanting to enable HTTPS on our OS Ticket server now. We are running CentOS 7.8 and 1.14.2 OSTicket. The OS Ticket guide says to just turn HTTPS on. If I do that, will it generate a self-signed cert and force everything to that? Will it give more menu options to choose what Cert I want the server to use? I have already generated a CSR and its been signed and created a public cert authority. I placed the appropriate certs in the correct /etc/pki folders. If I turn on HTTPS, will OS Ticket find those certs and every run with no issues? I have also seen where some people say to use a Virtual-Hosts file but since this will be the only web site on this server I am curious if its needed. I also do not have ssl-mod installed and am wondering if thats recommended or required. This will start out as an internal accessible website only but it will eventually be Public Accessible.

Thanks In advance. I've used Linux servers mainly for phone systems, MySQL, and file servers.... Web server is a new one for me.

ntozier

Daedalus01 If I do that, will it generate a self-signed cert and force everything to that?

No. That would need to be done on the webserver side by the server admin. SSL certs are installed in the webserver configuration not in [a web application] osTicket.

This article might help
https://www.digicert.com/kb/csr-ssl-installation/apache-openssl.htm

Daedalus01

Yup. I've seen that guide. Again, I have a SSL Cert installed in the /etc/pki folders as per the requirements for Apache and CentOS, but now I need to configure the webserver part to use them. Those recommend using a virtual host file. Can I not just tell httpd to use a certificate for the entire server? That document says to find the virtual host. I dont have a virtual host file.

Daedalus01

Ok, So I Install mod_ssl.

[david@troubletickets private]$ apachectl configtest
Syntax OK

I restart Apache and its running.

[david@troubletickets private]$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2020-05-19 10:31:30 CDT; 5s ago

website does not load over HTTPS. No errors when restarting Apache. Website still loads over port 80

My HTTPD.conf file containing the virtual host

<VirtualHost *:443>
DocumentRoot "/var/www/html/support"
ServerName troubletickets.domain.com
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/troubletickets.crt
SSLCertificateKeyFile /etc/pki/tls/private/TT.key
SSLCertificateChainFile /etc/pki/tls/certs/CA_Bundle.crt
<Directory "/var/www/html/support">
allow from all
Options None
Require all granted
</Directory>
</VirtualHost>

With Open SSL, I get the following error stating it cant verify the first certificate.

[david@troubletickets private]$ openssl s_client -connect troubletickets.goodygoody.com:443
CONNECTED(00000003)
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = troubletickets.goodygoody.com, emailAddress = root @troubletickets.goodygoody.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = troubletickets.goodygoody.com, emailAddress = root @troubletickets.goodygoody.com
verify error:num=21:unable to verify the first certificate
verify return:1

Daedalus01

Ok, So I had to open Port 443 in firewalld. In my httpd config even though I specified to use a specific Mozilla reports that I am using a self-signed certificate.

Daedalus01

Ok, I broke it even further. inside of the ssl.conf I have # out listen on 443. netstat still reports that my server is listening on 443 though.

[david@troubletickets _]$ sudo netstat -anp | grep 443
[sudo] password for david:
tcp6 0 0 :::443 :::* LISTEN 1197/httpd
udp 0 0 0.0.0.0:51443 0.0.0.0:* 809/avahi-daemon: r
[david@troubletickets _]$

the only thing in the httpd.conf file is my modified virtual host file, which I changed the port number .

[david@troubletickets conf]$ sudo cat httpd.conf | grep 443
<VirtualHost *:4443>

Even inside the ssl.conf, everything 443 related is commented out

[david@troubletickets conf.d]$ cat ssl.conf | grep 443
#Listen 443 https
#<VirtualHost default:443>
#ServerName www.example.com:443

This issue came around when I went into the system config for osTicket and enabled force all traffic to https. well that broke it, so I turned it off. It didnt seem to remove it though.

So with everything 443 listening turned off, something is still listening on 443 using the httpd daemon.

ntozier

Did you restart the Apache server after making the configuration change?

Daedalus01

I did. Now none of our agents can log into the SCP portal. Anyone that is an admin and an agent that trys to login, the screen just flashes and says authentication required. All Agents are authenticated through LDAP. I checked the LDAP server and everything is still running there.

edit -- and the user portal side is offline. So we cant even test that side.

Daedalus01

Ok, I was able to restore it to the point to where we can get the regular portal back up. No one is able to log in. The regular portal does the same trick. When users click sign in after entering their user name and password, the screen flashes briefly and acts like they weren't even trying to sign in.

jimatltr

So, you enable mod_ssl
Is the rewrite mod enabled?

You create the apache2 config for your site using a virtual host
You turn on ssl and point to the certs in the apache2 config for your site in the virtual host
You restart apache2
Did you enable the site "a2ensite site.conf"? OR Did you just modify the base config and add certs stuff and forget to have either both 80 and 443 in the site's config or have two separate configs where both have to be enabled?

sudo service apache2 status
or maybe
sudo systemctl status apache2

Shows what?

Daedalus01

This can be closed. I rebuilt the server using a different distro and HTTPS works without an issue now.

ntozier

Thanks for letting us know, although now I am curious as to what the issue was. 🙂

I'll close this thread.