smtp.gmail.com z bash podaje „Błąd w certyfikacie: wystawca certyfikatu partnera nie został rozpoznany”.


11

Potrzebowałem skryptu, aby wysłać e-maila do administratora, jeśli występuje problem, a firma korzysta tylko z Gmaila. Postępując zgodnie z instrukcjami dotyczącymi kilku postów, mogłem skonfigurować mailx przy użyciu pliku .mailrc. najpierw pojawił się błąd nss-config-dir Rozwiązałem to, kopiując niektóre pliki .db z katalogu Firefox. do ./certs i celowanie w mailrc. Wiadomość została wysłana.

Jednak pojawił się powyższy błąd. Jakimś cudem w pliku .db był certyfikat Google. Pojawiło się z tym poleceniem:

~]$ certutil -L -d certs

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

GeoTrust SSL CA                                              ,,
VeriSign Class 3 Secure Server CA - G3                       ,,
Microsoft Internet Authority                                 ,,
VeriSign Class 3 Extended Validation SSL CA                  ,,
Akamai Subordinate CA 3                                      ,,
MSIT Machine Auth CA 2                                       ,,
Google Internet Authority                                    ,,

Najprawdopodobniej można to zignorować, ponieważ poczta i tak działała. Wreszcie po wyciągnięciu włosów i wielu googli dowiedziałem się, jak pozbyć się irytacji.

Najpierw wyeksportuj istniejący certyfikat do pliku ASSCII:

~]$ certutil -L -n 'Google Internet Authority'  -d certs -a > google.cert.asc

Teraz ponownie zaimportuj ten plik i oznacz go jako zaufany dla certyfikatów SSL, między innymi:

~]$ certutil -A -t "C,," -n 'Google Internet Authority'  -d certs -i google.cert.asc

Następnie lista pokazuje, że jest zaufany:

~]$ certutil -L -d certs

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
...
Google Internet Authority                                    C,,

A mailx wysyła bez żadnych problemów.

~]$ /bin/mailx -A gmail -s "Whadda ya no" somebody@acompany.com
ho ho ho
EOT
~]$

Mam nadzieję, że jest to pomocne dla kogoś, kto chce naprawić błąd.

Ciekawe też coś.

Jak mogę uzyskać ten certyfikat, jeśli przypadkowo nie byłby w bazie danych Mozilli? Czy jest na przykład coś takiego?

    ~]$ certutil -A -t "C,," \
                 -n 'gmail.com'  \
                 -d certs \
                 -i 'http://google.com/cert/this...'

Odpowiedzi:


13

Cóż, nie chciałem tego jednego linera, ale oto jak pobrać i zaimportować certyfikat od zera:

# Create a certificate directory
~]$ mkdir certs

# Create a new database in the certs dir
~]$ certutil -N -d certs 

# Need now a chain certificate - May 18, 2015
~]$ wget https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.cer

# Need now a chain certificate part 2 - May 18, 2015
~]$ mv GeoTrust_Global_CA.cer certs/

# Fetch the certificate from Gmail, saving in the text file GMAILCERT
# Added the CA opion - May 18, 2015
~]$ echo -n | openssl s_client -connect smtp.gmail.com:465 -CAfile certs/GeoTrust_Global_CA.cer | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > GMAILCERT

# Import the new cert file into the new database in the new dir
~]$ certutil -A -n "Google Internet Authority" -t "C,," -d certs -i GMAILCERT 

# Double Check
~]$ certutil -L -d certs

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Google Internet Authority                                    C,,  

Yaa! i dzięki odpowiedzi na ten bilet


1
Ponownie pojawia się błąd „Błąd w certyfikacie: wystawca certyfikatu partnera nie został rozpoznany”. Certyfikat Gmail, który spożyłem, wygasł, wygląda na to, że nowy jest łańcuchem. openssl s_client -showcerts -connect smtp.gmail.com:465 </dev/nullaby zobaczyć je wszystkie.
spazm

1
Zaktualizowałem odpowiedź o krok, aby pobrać plik wystawcy certyfikatu.
ndasusers

Dzięki temu
biletowi

7

Ten post musi zostać ponownie zaktualizowany. Miałem problem z instalacją mailx na moim komputerze CentOS 7. Wiadomość e-mail zostanie wysłana, ale nadal pojawia się komunikat „Błąd certyfikatu: wystawca certyfikatu partnera nie jest rozpoznawany”. błąd.

Znalazłem tutaj rozwiązanie , musiałem je jednak przetłumaczyć.

Oto szybki sposób, aby to zrobić:

# Create a certificate directory
mkdir ~/.certs

# Create a new database in the certs dir (dont forget to enter your pass phrase!)
certutil -N -d ~/.certs 

# Create three files for the cert chain
touch ~/.certs/google ~/.certs/geotrust ~/.certs/equifax

# Copy the cert chain for smtp.google.com:465 over to my_certs file (don't forget the -showcerts option, CTRL + C to end this command)
openssl s_client -showcerts -connect smtp.gmail.com:465 > ~/.certs/my_certs

Teraz skopiuj każdy certyfikat, w tym - POCZĄTEK CERTYFIKAT - i - POTWIERDŹ CERTYFIKAT - i wklej je do odpowiednich plików, które wcześniej utworzyłeś (google, geotrust, equifax), a teraz zapisz te pliki.

# Open your my_certs file you made earlier and copy the google cert (usually the first one)
nano ~/.certs/my_certs

# Open your google file, paste the google cert that you just copied, and save and close
nano ~/.certs/google

# Open your my_certs file you made earlier and copy the geotrust cert (usually the second one)
nano ~/.certs/my_certs

# Open your geotrust file, paste the geotrust cert that you just copied, and save and close
nano ~/.certs/geotrust

# Open your my_certs file you made earlier and copy the equifax cert (usually the third one)
nano ~/.certs/my_certs

# Open your equifax file, paste the equifax cert that you just copied, and save and close
nano ~/.certs/equifax

Teraz musimy zaimportować każdy z tych certyfikatów do bazy danych.

# Import the google cert into the db
certutil -A -n "Google Internet Authority" -t "TC,," -d ~/.certs -i ~/.certs/google

# Import the geotrust cert into the db
certutil -A -n "GeoTrust Global CA" -t "TC,," -d ~/.certs -i ~/.certs/geotrust

# Import the equifax cert into the db
certutil -A -n "Equifax Secure Certificate Authority" -t "TCP,," -d ~/.certs -i ~/.certs/equifax

# Double check to make sure everything imported correctly into the db
certutil -L -d ~/.certs

Przykładowe dane wyjściowe:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Google Internet Authority                                    CT,,
GeoTrust Global CA                                           CT,,
Equifax Secure Certificate Authority                         CT,,

Czas czyszczenia (opcjonalnie)

# Remove all unnecessary files since the db has the certs :)
rm -rf ~/.certs/google ~/.certs/geotrust ~/.certs/equifax ~/.certs/my_certs

# Now run a test to make sure mailx is sending correctly now (don't forget to change yourname@example.com to the email address you'd like to send to)
echo "Your message" | mail -s "Message Subject" yourname@example.com

Tak powinno być, nie powinieneś otrzymywać komunikatu „Błąd w certyfikacie: wystawca certyfikatu partnera nie jest rozpoznawany”. błąd już więcej!

Uwagi:

Być może zauważyłeś, że zmieniłem katalog z /certsna ~/.certs. mailx działa jako root, więc właśnie wprowadziłem te zmiany jako root /. „~ /” Oznacza katalog domowy je połączyć ~/.certsśrodki /root/.certs/. Jestem pewien, że o tym wiedziałeś, ale hej, na wypadek, gdybyś nigdy nie wiedział, kto to czyta!

Na wypadek, gdybyś tego potrzebował, oto opcje konfiguracji, które dodałem na dole /etc/mail.rc

# /etc/mail.rc options added to the bottom
set smtp-use-starttls
set smtp-auth=login
set smtp=smtp://smtp.gmail.com:587
set from="your.from.user@gmail.com(Web01 Server)"
set smtp-auth-user=your.smtp.user@gmail.com
set smtp-auth-password=your.pass
set ssl-verify=ignore
set nss-config-dir=/root/.certs

Upewnij się, że zmieniłeś twój.fr.user, twój.smtp.user i twój.pass na odpowiednie zmienne.


Dzięki opteronom to działało jak urok, nie wiem, dlaczego @ndasusers nie działało.
Abhishek Madhani,

Czy ktoś wie, jak rozwiązać problem, gdy serwery poczty e-mail są zrównoważone pod względem obciążenia i działają jako klaster? np. Office 365 Certyfikat będzie sporadycznie pojawiał się błąd, ponieważ serwer na końcu połączenia zmienia się z połączenia na połączenie.
Brad

To znowu jest nieaktualne: -showcertsdaje dwa certyfikaty, a nie 3. Drugi to GlobalSign. Jednak ta procedura jest jedyną, która działa, więc +1: użyj -showcerts, znajdź wszystkie certyfikaty (obecnie 2) i zaimportuj je indywidualnie do bazy danych.
EML

... i działa openssljako echo -n | openssl, ot zawiesza się czekając na dane wejściowe
EML

@ EML + lub openssl s_client </dev/null. Tak, od 2017 r. Google (w tym Gmail) przeszedł z GIA2 pod GeoTrust / Equifax na GIA3 pod GlobalSign. Ale nie ma potrzeby przechowywania wszystkich certyfikatów łańcucha. A jeśli jakikolwiek przestępca lub oszust (jak wścibski rząd) podszywa się pod Gmaila, ta metoda nie tylko im ufa, ale czyni to na stałe - inni użytkownicy mogą zostać tymczasowo oszukani przez nielegalnie wydany certyfikat, ale gdy zostanie odwołany, przestaną mu ufać, podczas gdy dzięki temu metodą, którą nadal przekazujesz wszystkim swoim e-mailom złoczyńcom.
dave_thompson_085

0

Stworzyłem mały skrypt oparty na odpowiedziach w tym wątku, który automatycznie pobierze, parsuje i instaluje bieżące certyfikaty smtp gmail. Powinien być w stanie sobie z tym poradzić, jeśli ponownie zmieni się liczba certyfikatów.

Oto pastebin z podświetlaniem składni

#!/bin/bash

# This script pulls ssl certs for using gmail smtp. Adapted from the following config explaination:
# /server/498588/smtp-gmail-com-from-bash-gives-error-in-certificate-peers-certificate-issuer

certdirectory="/home/user/.certs"

# Functions

fail() {
    ec=$?
    [ "${ec}" == "0" ] && ec=1
    echo -e "FAILED[code=$ec]: $@"
    exit $ec
}

warn(){
echo -e "WARNING $@"
}

cleanup() {
  rm allgcert* || warn "Cleanup of files errored"
  rm gcert* || warn "Cleanup of files errored"
}

failclean() {
  cleanup
  fail "$@"
}

# Count number of certs currently being used (can change from time to time)
numcerts=$(echo -n | openssl s_client -showcerts -connect smtp.gmail.com:465 | grep -c "i:")

# Create the certs directory if it does not exist
mkdir -p $certdirectory || fail "Unable to create certificates directory"

# Pull certs to a local file for parsing
echo -n | openssl s_client -showcerts -connect smtp.gmail.com:465 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > allgcert || failclean "Unable to pull certs from smtp.gmail.com"

# Parses certs output based on the number of certs, and outputs to individual files
if (($numcerts > 1)) ; then
  # Pulls the first cert out as it needs one extra line
  sed '1,27!d' allgcert > gcert1
  # For subsequent certs, it multiplies the cert number by the number of lines in the file where it should exist
  for i in $(seq 2 $numcerts) ; do
    sed "$((2 + (((($i - 1)) * 26))))"','"$((1 + (($i * 26))))"'!d' allgcert > gcert${i}
  done
fi

# Parses out certificate issuer names for installation
echo -n | openssl s_client -showcerts -connect smtp.gmail.com:465 | grep i: | sed -e 's,.*=,,' > allgcertnames || failclean "Unable to output parsed names for certificates"

for i in $(seq 1 $numcerts) ; do
  certutil -A -n "$(sed -n ${i}p allgcertnames)" -t "TC,," -d $certdirectory -i gcert${i} || failclean "Unable to import certificates to database"
done

cleanup

Jak wyżej, jest to niewłaściwa rzecz, ale jeśli chcesz to zrobić, wystarczy jedna linia awk:openssl s_client </dev/null -showcerts -connect ... | awk '/^ i:/{n=substr($0,7)} /-BEGIN/,/-END/{print>"t"} /-END/{close("t"); system("certutil -A -n \"" n "\" -t TC,, -i t -d certdir || echo failed; rm t")}'
dave_thompson_085 24.08.19

Ach, nie widziałem twojego komentarza przed zbudowaniem tego skryptu. Dzięki! Edycja: po ponownym przeczytaniu jednego linijki nie widzę żadnej praktycznej różnicy między moim skryptem a tym. Zakładam, że właśnie dałeś mi w zasadzie jednoskładnikową wersję mojego skryptu. Czy istnieje zalecany „właściwy sposób”, aby to zrobić bez problemu stałego zaufania?
pyr0ball
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.