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: [email protected] Inspiration for the fix: http://colinnewell.wordpress.com/2011/03/11/ssl-host-checking-and-lwpuseragent/ 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
-------- RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
