Tony Upson's picture

Greetings,

I originally had the v13 VM appliance installed for the OTRS Ticketing System and saw that a recent v14 ISO release with OTRS is available. When I install, the WebAmin sections operate as intended, but the OTRS (Admin / Customer) HTTP pages aren't loading. Am I missing something? According to the 'change log' this was embed in this ISO, so I am assuming this should load by default since the OTRS Appliance GUI is displaying the URL's to each component. 

 

 

Forum: 
Tags: 
Tony Upson's picture

For those who are also running into this issue. I have found out the issue. The SSL (port 443) certificate .PEM embed within this ISO is invalid, corrupt or expired; thus Apache doesn't start. You have to create a new cert/key and associate the SSL connection to these new certificates. Below are the quick steps I did to achieve/resolve this issue:

 

******************************
Create new PEM / Certificate
******************************

The way I did this was by clicking "Advanced Menu" from the Console > and selecting Quit to get to the terminal screen.

Login with Admin Rights

Perform the following steps:

1. Start the new Cert request 

openssl req -new > new.ssl.csr

you're going to walk through a set of questions. when you get to the following questions:

* challenge password []:Leave Blank or you will be prompted everytime you reload apache
* An optional company name []:Optional

2. Create the new cert and key (PEM)

openssl rsa -in privkey.pem -out new.cert.key
openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey new.cert.key -days NNN

The -days option sets the length of time before the certificate expires. I went ahead and (roughly) calculated the time until the release of Ubuntu I'm using will be out of support. You can revoke a certificate or replace one before the cert expires, of course.

3. Now copy certs to the correct directory

cp new.cert.cert /etc/ssl/certs/<giveitaname>.crt
cp new.cert.key /etc/ssl/private/<giveitaname>.key

4. Within the Webmin GUI, go to Servers > Apache Webserver > click on the Virtual Server for SSL (443) connections > SSL Options > 

* Ensure SSL is enabled and only TLS 1.0/1.1 and 1.2 are checked
* Set the Certificate/private key to the <giveitaname>.crt and set the Private key file to the <giveitaname>.key file and save teh settings.

5. Start Apache

Problem resolved.

- Tony

Network Engineer

Federal Gov't

Jeremy Davis's picture

Yes it should. But it looks like the OTRS appliance has a bug. Sorry about that. We will need to rebuild this appliance. But in the meantime you should be able to fix your existing appliance from the commandline like this:
sed -i 's|^.*/etc/ssl/certs/cert.pem.*$||' /etc/otrs/apache.conf
service apache2 restart

Sorry about that. Let me know how it goes.

Tony Upson's picture

Thanks for the quick reply, my method resolved my issue before your reply, but your solution looks a lot easier to perform. So i will add this to my notes incase of another rebuild.

Quick question: According to your 9/15/2015 change log, indicates it is running the "Latest Debian Jessie package version of OTRS;" which appears to be v3.3.9. Just curious why none of the v4 builds are supported within these ISO's/Appliances or even the v3.3.12 version that is on the otrs.org download list as the latest for release 3. I feel like so much is being missed out with the 13 different versions of v4 be it v5 is out in 2 weeks. :D

- Tony

Network Engineer

Federal Gov't

Jeremy Davis's picture

It's luck of the draw really! :)

The reason for the issue is because we moved the default cert location as part of our SSL/TLS hardening. We moved the default declaration of the cert file into the Apache SSL module.

If you want to add a CA cert then it can still be enabled in (i.e. added to) individual site confs or changed in the ssl.conf for serverwide usage.

As to why we use an older version of OTRS: Your question has been covered in a few places on the forums. This thread covers it fairly completely. But the long and the short of it is; that unless the packaged (Debian repo) version contains significant bugs and/or the upstream version contains significant feature additions we choose the Debian version over upstream. The Debian version provides stability and security (auto security updates), it also requires less maintenance (for you and us).

Having said that, the value of a newer version can change over time. Bugs may be discovered or killer "must have" new features might be added. So we are always open to comment on this. If you find a significant bug in the included version (security bugs are patched by Debian & auto installed by TKL) or see a "must have" feature in a newer version then we can consider swapping it next release. Willingness to assist with appliance maintenance adds weight to the possibility of switching to upstream! :)

Tony Upson's picture

Thanks a lot, that makes perfect sense and i am ok with loading up the most secure and stable release. I appreciate it.

- Tony

Network Engineer

Federal Gov't

Add new comment