Hello,
I’ve had the same issues and am only now getting around to figuring it
out. Everything works fine in browser, but not thru rt-mailgate.
Every other service that uses the SSL keys are working; puzzled.
If I find something worthy of note, I’ll post it.
–Mark
Have you guys checked to ensure the linux box itself, I presume it is linux, acknowledges the validity of the certificate? (usually something like:
Just a quick openssl thought.From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Mark Story
Sent: Wednesday, January 11, 2012 1:04 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] rt-mailgate
Hello,
I’ve had the same issues and am only now getting around to figuring it out. Everything works fine in browser, but not thru rt-mailgate.
Every other service that uses the SSL keys are working; puzzled.
If I find something worthy of note, I’ll post it.
–Mark
Thanks for the suggestions guys.
I finally just turned off my re-write rule that was re-directing http
to https and side-stepped the rt-mailgate ssl failure all together.
Not ideal, but in practice very few of my users log into RT directly
so it’s a configuration I can live with short term while I figure out
the real issue.I’ve configured postfix to hand messages to the aliases for my queues
directly to rt-mailgate. It is rt-mailgate that cannot verify the ssl
certificate that my web server is presenting it. None of my web
browsers have trouble with it, so it feels like an rt-mailgate
configuration issue. I can repro the issue on the command line…
RT Training Sessions (http://bestpractical.com/services/training.html)
Sorry, left out the -CApath flag, and this is just for illustration:
root@xxx:/var/www/servers# openssl verify -CApath /etc/ssl/certs/ /usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt
/usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt: OKFrom: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Izz Abdullah
Sent: Wednesday, January 11, 2012 1:14 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] rt-mailgate
Have you guys checked to ensure the linux box itself, I presume it is linux, acknowledges the validity of the certificate? (usually something like:
Just a quick openssl thought.
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Mark Story
Sent: Wednesday, January 11, 2012 1:04 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] rt-mailgate
Hello,
I’ve had the same issues and am only now getting around to figuring it out. Everything works fine in browser, but not thru rt-mailgate.
Every other service that uses the SSL keys are working; puzzled.
If I find something worthy of note, I’ll post it.
–Mark
Thanks for the suggestions guys.
I finally just turned off my re-write rule that was re-directing http
to https and side-stepped the rt-mailgate ssl failure all together.
Not ideal, but in practice very few of my users log into RT directly
so it’s a configuration I can live with short term while I figure out
the real issue.I’ve configured postfix to hand messages to the aliases for my queues
directly to rt-mailgate. It is rt-mailgate that cannot verify the ssl
certificate that my web server is presenting it. None of my web
browsers have trouble with it, so it feels like an rt-mailgate
configuration issue. I can repro the issue on the command line…
RT Training Sessions (http://bestpractical.com/services/training.html)
I’ve had the same issues and am only now getting around to figuring it
out. Everything works fine in browser, but not thru rt-mailgate.
Every other service that uses the SSL keys are working; puzzled.
We have a branch (not yet merged) that improves the doc for using
rt-mailgate with SSL:
https://github.com/bestpractical/rt/compare/4.0-trunk...4.0%2Fmailgate-ssl-deps
Make sure you have Crypt::SSLeay, Net::SSL, LWP::UserAgent,
LWP::Protocol::https, and Mozilla::CA installed.
Thomas
500 Can’t connect to
request.domain.com:443 (certificate
verify failed)/opt/rt4/bin/rt-mailgate: undefined server error
Yes, I got the same problem Monday after installing an “Extended
Validation” SSL certificate on the same Apache2 server as RT. RT is
accessible only over SSL using a wildcard cert, and some other
virtualhosts use the same wildcard cert. All the virtualhosts, RT
included, have the same IP address, which means the client needs to
understand TLS in order to get Apache to present to correct
certificate for the correct hostname.
When all the Virtualhosts used the same wildcard SSL cert, mailgate
worked fine. As soon as one of the Virtualhosts used a different cert,
mailgate fails with the above error to connect to RT to stuff the
message in.
This is on Ubuntu 11.10 Oneiric running reqest-tracker4 pinned with
apt preferences to “Precise” packages for version 4.0.4-1:
root@web0:/etc/logrotate.d# dpkg --list | grep reques
ii request-tracker4 4.0.4-1
extensible trouble-ticket tracking system
ii rt4-apache2 4.0.4-1
Apache 2 specific files for request-tracker4
ii rt4-clients 4.0.4-1
mail gateway and command-line interface to request-tracker4
ii rt4-db-sqlite 4.0.4-1
SQLite database backend for request-tracker4
I think something is wrong in the rt-mailgate-4 script that doesn’t
understand TLS or when something happens and it gets a certificate
whose hostname does not match with the host that it is connecting to.
A
root@xxx:/var/www/servers# openssl verify -CApath /etc/ssl/certs/ /usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt
/usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt: OK
Yes, that is the same output I get when running the command.
The problem is that only rt-mailgate is having a problem figuring out
how to validate the SSL certificate that RT instance is using. All
browser clients validate it fine.
This thread from October 2011
Carbon60: Managed Cloud Services talks about
editting rt-mailgate to specifically name a root ca as an ssl_option
argument, but I really don’t want to mess with the RT distribution and
feel I shouldn;t have to because it worked fine with the old wildcard
SSL cert, and browsers were able to figure out the new SSL cert
without trouble as well.
A
Hello,
I verified my certificates, openssl says they’re OK.
–Mark
Make sure you have Crypt::SSLeay, Net::SSL, LWP::UserAgent,
LWP::Protocol::https, and Mozilla::CA installed.
We didn’t have Mozilla::CA & Crypt::SSLeay installed, but still didn’t
help:
rt> ls -t 59
Query:Status!=‘resolved’ and Status!=‘rejected’
rt: Server error: Can’t connect to rt.myhost.com:443 (certificate verify
failed) (500)
–Mark
I have rt4 installed manually in /opt/rt4 but when I ran dpkg I got:
www:/etc/ssl/certs# dpkg --list | grep reques
ii libapache2-mod-apreq2 2.08-5+b1 generic
Apache request library - Apache modu
ii libapache2-request-perl 2.08-5+b1 generic
Apache request library - Perl module
ii libapreq2 2.08-5+b1 generic
Apache request library
pc request-tracker3.6 3.6.7-5+lenny6
Extensible trouble-ticket tracking system
pc rt3.6-db-postgresql 3.6.7-5+lenny6
PostgreSQL database backend for request-trac
Is that a potential issue? I tried removing request-tracker3.6 &
rt3.6-db-postgresql but it failed …?
www:/etc/ssl/certs# apt-get remove rt3.6-db-postgresql
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package rt3.6-db-postgresql is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 48 not upgraded.
www:/etc/ssl/certs# apt-get remove request-tracker3.6
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package request-tracker3.6 is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 48 not upgraded.
–Mark
pc request-tracker3.6 3.6.7-5+lenny6 Extensible trouble-ticket
tracking system
pc rt3.6-db-postgresql 3.6.7-5+lenny6 PostgreSQL database backend
for request-trac
“p” in first column means already marked for purging.
“c” in second column means configuration files from those are still present
try: dpkg --purge
I figured out a work around for this issue. I was suspicious that
LWP::UserAgent could not reach the cert for the CA that signed the cert
being presented by the web server. I learned there are some environment
variables that I can leverage to influence where LWP::UserAgent looks even
though it’s being invoked down inside a program I don’t want to touch.
Adding my /etc/ssl/certs directory to the list of directories examined for
certs solved the problem.
*root@linux:/opt/rt4/bin# *./rt-mailgate --debug --action=correspond
–queue=ToDo --url=https://request.domain.com < ~/test.msg
./rt-mailgate: temp file is ‘/tmp/MqO8Gyi3SW/ILtfyOuDPb’
./rt-mailgate: connecting to
https://request.domain.com/REST/1.0/NoAuth/mail-gateway
An Error Occurred
500 Can’t connect to
request.domain.com:443 (certificate
verify failed)
./rt-mailgate: undefined server error
*root@linux:/opt/rt4/bin# *export PERL_LWP_SSL_CA_PATH=/etc/ssl/certs
root@linux:/opt/rt4/bin# ./rt-mailgate --debug --action=correspond
–queue=ToDo --url=https://request.domain.com < ~/test.msg
./rt-mailgate: temp file is ‘/tmp/rn88yVfFtr/IVe9YYO9IY’
./rt-mailgate: connecting to
https://request.domain.com/REST/1.0/NoAuth/mail-gateway
okTicket: 7698Queue: ToDoOwner: ran1Status: newSubject: testRequestor:
robert.nesius@domani.com
Inspiration for the fix:
Ultimately I suppose I can wrap rt-mailgate with a script that sets the
environment variable and exec’s rt-mailgate, or I could perhaps embed
setting the environment variable along with the invocation of rt-mailgate
in the aliases file. I’ll figure something out.
-Rob
I figured out a work around for this issue. I was suspicious that
LWP::UserAgent could not reach the cert for the CA that signed the cert
being presented by the web server. I learned there are some environment
variables that I can leverage to influence where LWP::UserAgent looks
even though it’s being invoked down inside a program I don’t want to
touch. Adding my /etc/ssl/certs directory to the list of directories
examined for certs solved the problem.
For what it’s worth, the next release of RT will include a --ca-file
option you can use to specify the specific cert. It’s equivalent to
setting PERL_LWP_SSL_CA_FILE.
*root@linux:/opt/rt4/bin# *export PERL_LWP_SSL_CA_PATH=/etc/ssl/certs
If you’d like to submit a simple patch to rt-mailgate that also adds
support for --ca-path, I’m sure we’d apply it.
I do wonder why the OpenSSL library underlying the Perl library isn’t
finding your cert in /etc/ssl/certs like I’d expect it to.
Thomas
I tried several things to get the cert path into the environment for LWP,
none worked:
Adding this to /etc/fetchmailrc
mda "env PERL_LWP_SSL_CA_PATH=/etc/ssl/certs /usr/bin/rt-mailgate-4 …
does NOT work to get the right cert to LWP through the environment:
root@web0:/etc# service fetchmail start
Starting mail retriever agent:
fetchmail:
starting fetchmail 6.3.19 daemon
[ OK ]
root@web0:/etc# fetchmail: 1 message for [email address] at
[imapmailserver] (folder Support).
An Error Occurred
500 Can’t connect to [RT webserver]:443
(certificate verify failed)
Adding this to fetchmailrc does not work either:
mda "export PERL_LWP_SSL_CA_PATH=/etc/ssl/certs; /usr/bin/rt-mailgate-4
…
Adding this to /etc/default/fetchmail on Ubuntu where fetchmail runs
from an init script as a daemin does not work either:
export PERL_LWP_SSL_CA_PATH=/etc/ssl/certs
I am stuck with having to edit the rt-mailgate-4 on line 151 file like this:
my $ua = LWP::UserAgent->new(ssl_opts => {SSL_ca_file =>
‘/etc/ssl/certs/7d3cd826.0’});
which I dont like because I will forget about it during upgrade.
AOn Mon, Jan 23, 2012 at 11:06 AM, Thomas Sibley trs@bestpractical.com wrote:
On 01/20/2012 02:38 PM, Robert Nesius wrote:
I figured out a work around for this issue. I was suspicious that
LWP::UserAgent could not reach the cert for the CA that signed the cert
being presented by the web server. I learned there are some environment
variables that I can leverage to influence where LWP::UserAgent looks
even though it’s being invoked down inside a program I don’t want to
touch. Adding my /etc/ssl/certs directory to the list of directories
examined for certs solved the problem.For what it’s worth, the next release of RT will include a --ca-file
option you can use to specify the specific cert. It’s equivalent to
setting PERL_LWP_SSL_CA_FILE.*root@linux:/opt/rt4/bin# *export PERL_LWP_SSL_CA_PATH=/etc/ssl/certs
If you’d like to submit a simple patch to rt-mailgate that also adds
support for --ca-path, I’m sure we’d apply it.I do wonder why the OpenSSL library underlying the Perl library isn’t
finding your cert in /etc/ssl/certs like I’d expect it to.Thomas
RT Training Sessions (http://bestpractical.com/services/training.html)
- Boston March 5 & 6, 2012
I made a recently change to how my apache2 server was configured to
redirect all requests through https. Now emails are not flowing through to
RT - I tracked the issue down to rt-mailgate complaining about not being
able to verify the certificate. I’m a little perplexed on how to proceed
or how to verify what certs/CAs rt-mailgate is using, or if there is an
issue with the Crypt::SSLeay module (which I had to force install due to a
failing test). I only have one openssl install on the system, and I
thought Crypt::SSLeay would reach through to those configs for things like
CA certs, etc…Perhaps an easy workaround, since the mail server and apache2 server are
on the same machine, would be to configure a “localhost:80” virtual host
within apache2 and bypass SSL when accessing RT via that url.Any helpful hints/suggestions would be greatly appreciated. I’ve been
google-ing away but haven’t had any luck yet.
We simply use mod_rewrite to redirect everyone except the server itself
to https. This way when rt-mailgate calls http://rt.ourdomain/com it is
not forced to use https while everyone else is.
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^10.10.227.209$
RewriteRule ^/(.*)$ https://rt.ourdomain.com/$1 [R=301,L]
The 10.10.227.209 is the IP address of the server according to ifconfig
eth0 in this case.
Landon Stewart LStewart@Superb.Net
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more “Ahead of the Rest”: http://www.superbhosting.net
We simply use mod_rewrite to redirect everyone except the server itself
to https. This way when rt-mailgate calls http://rt.ourdomain/com it is
not forced to use https while everyone else is.
Thanks. That is an easy, maintainable solution until the next version of
rt-mailgate that will let us specify the cert path, or until OpenSSL 1.x
gets it’s act together with LWP.
But doesn’t work for me. I solved some kind of mod-perl/apache
redeclaration or some such problem (either spamming the logs or making
apache not start – cant remember which) that I solved by removing all RT
apache configuration under regular http and just having the redirect to
SSL. The SSL virtualhost container has the RT configs in it.
A
Landon wrote:
We simply use mod_rewrite to redirect everyone except the server itself
to https. This way when rt-mailgate calls http://rt.ourdomain/com it is
not forced to use https while everyone else is.
Landon - thank you for sharing those config lines. I had debated exactly
that approach but had not dug into the mod-rewrite docs far enough to get
that line on my own. Though - as I look at it - pretty simple regular
expression. 
Thanks again!
Thanks. That is an easy, maintainable solution until the next version of
rt-mailgate that will let us specify the cert path, or until OpenSSL 1.x
gets it’s act together with LWP.But doesn’t work for me. I solved some kind of mod-perl/apache
redeclaration or some such problem (either spamming the logs or making
apache not start – cant remember which) that I solved by removing all RT
apache configuration under regular http and just having the redirect to
SSL. The SSL virtualhost container has the RT configs in it.
One other thought crossed my mind reading your earlier comments about
getting the environment variable into LWP::UserAgent via fetchmail configs.
I think “export VAR=VALUE” is bash-specific syntax. If the fetchmailrc
file is being read by /bin/sh, or bash running in /bin/sh compatibility
mode, that syntax could cause a problem. You might try this: "VAR=VALUE
/opt/rt4/bin/rt-mailgate … ". That syntax works for me via my aliases
file and is what I use in crontabs too. I did see you use that syntax with
the env command - I’ve never tried that before myself but I’ve never needed
it either.
-Rob
Hi
We let Apache authenticate under SSL but had problems with rt-mailgate.
Our work around was to configure httpd.conf as below so that rt-mailgate
could operate under port 80. No doubt there are better ways, but this is
working for us.
<Location “/rt4/NoAuth/”>
Order allow,deny
Allow from all
Satisfy Any
<Location “/rt4/REST/1.0/NoAuth/”>
Order allow,deny
Allow from all
Satisfy Any
<LocationMatch “^/rt4/($|[^NR])”>
SSLRequireSSL
AuthType […]
Require valid-user
Jim Berry