RT:Request Tracker – Chyba:rt-mailgate – Nedefinovaná chyba serveru – 500 Nelze se připojit nebo ověřit certifikát [Vyřešeno]

Nainstaloval jsem si do kanceláře Request Tracker (RT) a do dneška fungoval dobře. Najednou přestala přijímat žádosti o lístky prostřednictvím pošty a uživateli/žadateli se neobjevila žádná vrácená pošta ani se nezobrazila chyba. Zde je návod, jak jsem problém odladil – první věc, kterou jsem udělal, bylo ověřit, zda se požadavek na e-mail dostává na stroj RT (z poštovního serveru) a skutečně funguje dobře. Ale pak se tiket jednoduše nevytvořil a naštěstí se /var/log/maillog měla níže uvedenou chybovou zprávu a byla zachycena při vytváření lístku pomocí rt-mailgate perl skript.

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=<[email protected]> (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

K získání podrobné chyby jsem použil –debug možnost pro rt-mailgate skript, jak je uvedeno níže:

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

Poznámka:„test“ je vzorový soubor s ukázkovým textem/zprávou.

a zde je obdržená chyba:

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

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

Z této chybové zprávy vyplývá, že tuto chybu spustil certifikát SSL použitý pro instanci RT. Pokud jde o certifikát SSL, je třeba ověřit dvě věci.

1. Ověřte certifikát SSL používaný instancí RT:

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

Výše uvedený příkaz vrátil stav „OK“. Když se k RT přistupuje přes https prostřednictvím webového prohlížeče, překvapivě to nemělo žádný problém (ale nefungovalo to v příkazovém řádku). Abych si ujasnil, že funkce z několika perlových modulů nejsou poškozené, aktualizoval jsem níže uvedené perlové moduly pomocí cpan:

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

Původní problém však stále nebyl vyřešen. Po hodinovém googlování jsem našel opravu pro rt-mailgate, abych opravil ověření SSL na POSIX – buď nastavením proměnné prostředí PERL_LWP_SSL_VERIFY_HOSTNAMES nebo řekněte uživatelskému agentovi, aby ignoroval ověření názvů hostitelů a SSL pomocí možností, jak je uvedeno níže. Chcete-li to provést, vyhledejte níže uvedený řádek v /opt/rt3/bin/rt-mailgate

my $ua = new LWP::UserAgent;

Přidejte níže uvedený řádek, který informuje user-agent o vaší cestě ROOT CA:

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

Upozornění: Vezměte na vědomí, že výše uvedený postup otevře zranitelnost. Bude to fungovat, protože použití certifikátu je ignorováno, ale server může být zranitelný vůči útoku MITM.

2. Ověřit důvěryhodnost certifikátu SSL, který instance RT používá?

V mém případě jsem použil certifikát podepsaný svým držitelem a (nevytvořil jsem žádný certifikát ROOT CA nebo jej možná nejsem schopen sledovat), který nebyl důvěryhodný! Pokud stále chcete používat certifikáty podepsané svým držitelem, můžete postupovat podle části Vytvoření vlastní certifikační autority SSL (a Ukládání certifikátů s vlastním podpisem) a vytvořte certifikáty ROOT CA a certifikáty s vlastním podpisem. Zkopírujte ROOT CA do umístění /etc/pki/CA/certs . Pokud toto umístění není k dispozici, musíte nainstalovat ca-certificates-2010.63-3.el6_1.5.noarch RPM balíček.

Nakonec se mi podařilo spustit rt-mailgate úspěšně. Pokud vaše ROOT CA není ve standardním umístění, můžete je zadat v rt-mailgate jak naznačuje blogový příspěvek mozku. Najděte níže uvedený řádek v /opt/rt3/bin/rt-mailgate

my $ua = new LWP::UserAgent;

Přidejte níže uvedený řádek, který informuje user-agent o vaší cestě ROOT CA.

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

Poznámka: Nezapomeňte ve výše uvedeném řádku nastavit správnou cestu ROOT CA.

A je to! Doufám, že moje zkušenost může někomu pomoci.