We recently changed to a new SSL cert with a new CA. After replacing the private key and cert, https works correctly with RT’s web interface. But incoming emails get stuck in queue, with this message in exim’s logs:
2015-02-04 10:04:23 1YJ4JK-0000LE-V7 help@ourdomain: rt_help_transport transport output: An Error Occurred
2015-02-04 10:04:23 1YJ4JK-0000LE-V7 == help@ourdomain
R=rt_stathelp_router T=rt_stathelp_transport defer (0): Child process of rt_stathelp_transport transport returned 75 (could mean temporary error) from command: /usr/bin/rt-mailgate
We’re running RT 4.0.7-5 on Debian 7. After reverting back to the old cert, everything is working again.
We recently changed to a new SSL cert with a new CA. After replacing the private key and cert, https works correctly with RT’s web interface. But incoming emails get stuck in queue, with this message in exim’s logs:
2015-02-04 10:04:23 1YJ4JK-0000LE-V7 help@ourdomain: rt_help_transport transport output: An Error Occurred
2015-02-04 10:04:23 1YJ4JK-0000LE-V7 == help@ourdomain
R=rt_stathelp_router T=rt_stathelp_transport defer (0): Child process of rt_stathelp_transport transport returned 75 (could mean temporary error) from command: /usr/bin/rt-mailgate
We’re running RT 4.0.7-5 on Debian 7. After reverting back to the old cert, everything is working again.
Any suggestions?
Thanks!
If it’s not a mainstream trusted CA, check out the --ca-cert option for
rt-mailgate.
We recently changed to a new SSL cert with a new CA. After replacing the private key and cert, https works correctly with RT’s web interface. But incoming emails get stuck in queue, with this message in exim’s logs:
2015-02-04 10:04:23 1YJ4JK-0000LE-V7 help@ourdomain: rt_help_transport transport output: An Error Occurred
2015-02-04 10:04:23 1YJ4JK-0000LE-V7 == help@ourdomain
R=rt_stathelp_router T=rt_stathelp_transport defer (0): Child process of rt_stathelp_transport transport returned 75 (could mean temporary error) from command: /usr/bin/rt-mailgate
We’re running RT 4.0.7-5 on Debian 7. After reverting back to the old cert, everything is working again.
Any suggestions?
Thanks!
If it’s not a mainstream trusted CA, check out the --ca-cert option for
rt-mailgate.
It is a trusted CA, and the cert for the CA is present on the server. That’s why I’m so baffled by the problem - the whole cert chain works fine with the web interface.
It is a trusted CA, and the cert for the CA is present on the server.
That’s why I’m so baffled by the problem - the whole cert chain works
fine with the web interface.
Have you tried passing the CA, and it didn’t work, or did you note try
yet? Perl may be working from a different certificate store than your
web browser.
Alternately, try upgrading Net::SSLeay and LWP::Protocol::https.
It is a trusted CA, and the cert for the CA is present on the server.
That’s why I’m so baffled by the problem - the whole cert chain works
fine with the web interface.
Have you tried passing the CA, and it didn’t work, or did you note try
yet? Perl may be working from a different certificate store than your
web browser.
Alternately, try upgrading Net::SSLeay and LWP::Protocol::https.
Alex
rt-mailgate doesn’t work whether or not the --ca-file option is set. After tinkering with the rt-mailgate code a bit, I found that if I set the CA path in addition to the CA file, it does work (or at least, it gets as far as producing an invalid user error):
$ua->ssl_opts( SSL_ca_path => “/etc/ssl/certs/”);
According to the LWP documentation, the default for SSL_ca_path is set by checking these environment variables: PERL_LWP_SSL_CA_PATH and HTTPS_CA_DIR
Since I don’t want to have my crudely hacked version of rt-mailgate in use, I’d prefer to append /etc/ssl/certs/ to one of the above environment variables in a config file. Is there a place within the RT config files that this can be done?