RT:Request Tracker – Error : rt-mailgate – Undefined server error – 500 Can’t connect or verify Certificate [Solved]

Updated on September 3, 2017

I have installed Request Tracker (RT) in my office and it was working well until today.  Suddenly, it stopped accepting ticket requests via Mail and there was no bounce mail or an error shown to the user/requestor. Here’s how I debugged the issue – the first thing I did was to verify if the mail request was reaching the RT machine (from mail server) and it was indeed, working fine. But then, the ticket were simply not getting created and fortunately, the /var/log/maillog had the below error message and it was captured while creating the ticket with rt-mailgate perl script.

Jun 10 17:03:50 support sendmail[1953]: t5ABXovT001952: to="|/opt/rt3/bin/rt-mailgate --queue default --action correspond --url http://rt.techglimpse.com/", ctladdr=<rt-default@support.techglimpse.com> (8/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=34931, dsn=4.0.0, stat=Deferred: prog mailer (/usr/sbin/smrsh) exited with EX_TEMPFAIL

To get a detailed error, I used –debug option for rt-mailgate script as shown below:

RT: Request Tracker error

/opt/rt3/bin/rt-mailgate --queue default --action correspond --url https://rt.techglimpse.com:443/ --debug < test

Note: ‘test’ is a sample file with a sample text/message.

and here’s the error obtained :

500 Can't connect to rt.techglimpse.com:443
(certificate verify failed)

/opt/rt3/bin/rt-mailgate: undefined server error

With this error message, the inference is that the SSL certificate used for RT Instance has triggered this error. There are two things to verify regarding the SSL certificate.

1. Verify SSL certificate used by RT instance :

openssl verify /etc/httpd/conf/ssl.crt/rt.techglimpse.com.crt

The above command returned status “OK”. Surprisingly, when RT is accessed over https through web browser, it didn’t had any problem (but it didn’t work in the command line). To make myself clear that the functions from few perl modules are not broken, I just updated below perl modules through cpan:

LWP::UserAgent, Crypt::SSLeay, LWP::Protocol::https HTTP::Cookies

But still the original issue was not yet solved. After googling for an hour, I across a patch for rt-mailgate, to correct SSL verification on POSIX – either by setting the environment variable PERL_LWP_SSL_VERIFY_HOSTNAMES or tell the user-agent to ignore the verification of hostnames and the SSL using options as shown below. To do that, just search for the below line in /opt/rt3/bin/rt-mailgate

my $ua = new LWP::UserAgent;

Add the below line which tells the user-agent about your ROOT CA path:

$ua->ssl_opts( verify_hostnames => 0 );

Warning : Just take note here, as the above procedure will open up a vulnerability. It will work, as the certificate usage is being ignored, but the server might be vulnerable to MITM attack.

2. Verify SSL certificate trust that RT instance is using?

In my case, I used self-signed certificate and (I had not created any ROOT CA Certificate or may be I’m not able to track one) that wasn’t trusted! If you still want to use self-signed certificates, you can follow Creating Your Own SSL Certificate Authority (and Dumping Self Signed Certs) to create ROOT CA and self-signed certificates. Copy ROOT CA to the location /etc/pki/CA/certs. If this location is not present, then you need to install ca-certificates-2010.63-3.el6_1.5.noarch RPM package.

Finally, I was able to execute rt-mailgate successfully. If your ROOT CA is not in the standard location, you can specify them in rt-mailgate as suggested by brain’s blog post. Find the below line in /opt/rt3/bin/rt-mailgate

my $ua = new LWP::UserAgent;

Add the below line which tells the user-agent about your ROOT CA path.

$ua->ssl_opts( SSL_ca_file => '/path/to/root.crt' );

Note: Remember to set the correct path of the ROOT CA in the above line.

That’s it! Hope my experience might help someone out there.

Was this article helpful?

Related Articles

Leave a Comment