Szyfrowanie przy użyciu certyfikatów

Omówienie

Zabbix może używać certyfikatów RSA w formacie PEM, podpisanych przez publiczny lub wewnętrzny urząd certyfikacji (CA).

Weryfikacja certyfikatu jest wykonywana względem wstępnie skonfigurowanego certyfikatu CA. Opcjonalnie można używać list odwołanych certyfikatów (CRL).

Każdy komponent Zabbix może mieć skonfigurowany tylko jeden certyfikat.

Więcej informacji na temat konfiguracji i obsługi wewnętrznego CA, generowania i podpisywania żądań certyfikatów oraz unieważniania certyfikatów można znaleźć w samouczkach, takich jak OpenSSL PKI Tutorial v2.0.

Należy dokładnie rozważyć i przetestować rozszerzenia certyfikatu. Więcej informacji można znaleźć w sekcji Ograniczenia dotyczące używania rozszerzeń certyfikatu X.509 v3.

Parametry konfiguracji certyfikatów

Poniższe parametry konfiguracji są obsługiwane podczas konfigurowania certyfikatów na komponentach Zabbix.

Parameter Mandatory Description
TLSCAFile yes Pełna ścieżka do pliku zawierającego certyfikaty nadrzędnego urzędu CA do weryfikacji certyfikatu drugiej strony.
Jeśli używasz łańcucha certyfikatów z wieloma elementami, uporządkuj certyfikaty tak, aby najpierw znajdowały się certyfikaty CA niższego poziomu, a następnie certyfikaty CA wyższego poziomu.
Certyfikaty z wielu urzędów CA mogą być umieszczone w jednym pliku.
TLSCRLFile no Pełna ścieżka do pliku zawierającego listy unieważnionych certyfikatów (CRL).
TLSCertFile yes Pełna ścieżka do pliku zawierającego certyfikat.
Jeśli używasz łańcucha certyfikatów z wieloma elementami, uporządkuj certyfikaty tak, aby najpierw znajdował się certyfikat serwera, proxy lub agenta, następnie certyfikaty CA niższego poziomu, a na końcu certyfikaty CA wyższego poziomu.
TLSKeyFile yes Pełna ścieżka do pliku zawierającego klucz prywatny.
Upewnij się, że ten plik jest czytelny wyłącznie dla użytkownika Zabbix, ustawiając odpowiednie prawa dostępu.
TLSServerCertIssuer no Dozwolony wystawca certyfikatu serwera.
TLSServerCertSubject no Dozwolony podmiot certyfikatu serwera.

Przykłady konfiguracji

Po skonfigurowaniu niezbędnych certyfikatów skonfiguruj komponenty Zabbix do korzystania z szyfrowania opartego na certyfikatach.

Poniżej znajdują się szczegółowe kroki konfiguracji:

serwer Zabbix

1. Przygotuj plik certyfikatu CA.

Aby zweryfikować certyfikaty peerów, serwer Zabbix musi mieć dostęp do pliku zawierającego najwyższego poziomu, samopodpisane certyfikaty głównego CA. Na przykład, jeśli potrzebne są certyfikaty z dwóch niezależnych głównych CA, umieść je w pliku /home/zabbix/zabbix_ca_file.crt:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 CA
            ...
        Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
            ...
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            ...
-----BEGIN CERTIFICATE-----
MIID2jCCAsKgAwIBAgIBATANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB
....
9wEzdN8uTrqoyU78gi12npLj08LegRKjb5hFTVmO
-----END CERTIFICATE-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2 CA
            ...
        Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2 CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
            ....
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            ....       
-----BEGIN CERTIFICATE-----
MIID3DCCAsSgAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQB
...
vdGNYoSfvu41GQAR5Vj5FnRJRzv5XQOZ3B6894GY1zY=
-----END CERTIFICATE-----

2. Umieść certyfikat/łańcuch certyfikatów serwera Zabbix w pliku, na przykład w /home/zabbix/zabbix_server.crt. Pierwszy certyfikat to certyfikat serwera Zabbix, a następnie certyfikat pośredniego CA:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Signing CA
        ...
        Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Zabbix server
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                ...
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: 
                CA:FALSE
            ...
-----BEGIN CERTIFICATE-----
MIIECDCCAvCgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixk
...
h02u1GHiy46GI+xfR3LsPwFKlkTaaLaL/6aaoQ==
-----END CERTIFICATE-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 CA
        ...
        Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Signing CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
            ...
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
        ...
-----BEGIN CERTIFICATE-----
MIID4TCCAsmgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB
...
dyCeWnvL7u5sd6ffo8iRny0QzbHKmQt/wUtcVIvWXdMIFJM0Hw==
-----END CERTIFICATE-----

Używaj wyłącznie atrybutów wymienionych powyżej zarówno dla certyfikatów klienta, jak i serwera, aby nie wpływać na proces weryfikacji certyfikatu. Na przykład OpenSSL może nie zdołać nawiązać szyfrowanego połączenia, jeśli używane są rozszerzenia X509v3 Subject Alternative Name lub Netscape Cert Type. Więcej informacji znajdziesz w sekcji Ograniczenia dotyczące używania rozszerzeń certyfikatów X.509 v3.

3. Umieść klucz prywatny serwera Zabbix w pliku, na przykład w /home/zabbix/zabbix_server.key:

-----BEGIN PRIVATE KEY-----
MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQC9tIXIJoVnNXDl
...
IJLkhbybBYEf47MLhffWa7XvZTY=
-----END PRIVATE KEY-----

4. Edytuj parametry konfiguracji TLS w pliku konfiguracyjnym serwera Zabbix:

TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSCertFile=/home/zabbix/zabbix_server.crt
TLSKeyFile=/home/zabbix/zabbix_server.key
Zabbix proxy

1. Przygotuj pliki z certyfikatami CA najwyższego poziomu, certyfikatem/łańcuchem certyfikatów Zabbix proxy oraz kluczem prywatnym, zgodnie z opisem w sekcji Zabbix server. Następnie odpowiednio edytuj parametry TLSCAFile, TLSCertFile i TLSKeyFile w pliku konfiguracyjnym Zabbix proxy.

2. Edytuj dodatkowe parametry TLS w pliku konfiguracyjnym Zabbix proxy:

  • Dla aktywnego proxy: TLSConnect=cert
  • Dla pasywnego proxy: TLSAccept=cert

Aby zwiększyć bezpieczeństwo proxy, możesz również ustawić parametry TLSServerCertIssuer i TLSServerCertSubject. Więcej informacji znajdziesz w sekcji Ograniczanie dozwolonego wystawcy i podmiotu certyfikatu.

Parametry TLS w końcowym pliku konfiguracyjnym proxy mogą wyglądać następująco:

TLSConnect=cert
TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSCertFile=/home/zabbix/zabbix_proxy.crt
TLSKeyFile=/home/zabbix/zabbix_proxy.key

3. Skonfiguruj szyfrowanie dla tego proxy w frontend Zabbix:

  • Przejdź do: Administration > Proxies.
  • Wybierz proxy i kliknij kartę Encryption.

W poniższych przykładach pola Issuer i Subject są wypełnione. Więcej informacji o tym, dlaczego i jak używać tych pól, znajdziesz w sekcji Ograniczanie dozwolonego wystawcy i podmiotu certyfikatu.

Dla aktywnego proxy:

Dla pasywnego proxy:

Zabbix agent

1. Przygotuj pliki z certyfikatami CA najwyższego poziomu, certyfikatem/łańcuchem certyfikatów Zabbix agent oraz kluczem prywatnym, zgodnie z opisem w sekcji Zabbix server. Następnie odpowiednio edytuj parametry TLSCAFile, TLSCertFile i TLSKeyFile w pliku konfiguracyjnym Zabbix agent.

2. Edytuj dodatkowe parametry TLS w pliku konfiguracyjnym Zabbix agent:

  • Dla aktywnego agenta: TLSConnect=cert
  • Dla pasywnego agenta: TLSAccept=cert

Aby zwiększyć bezpieczeństwo agenta, możesz ustawić parametry TLSServerCertIssuer i TLSServerCertSubject. Więcej informacji znajdziesz w sekcji Ograniczanie dozwolonego wystawcy i podmiotu certyfikatu.

Parametry TLS w końcowym pliku konfiguracyjnym agenta mogą wyglądać następująco. Zwróć uwagę, że w przykładzie założono, iż host jest monitorowany przez proxy, dlatego jest ono określone jako Subject certyfikatu:

TLSConnect=cert
TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSCertFile=/home/zabbix/zabbix_agentd.crt
TLSKeyFile=/home/zabbix/zabbix_agentd.key

3. Skonfiguruj szyfrowanie w frontend Zabbix dla hosta monitorowanego przez tego agenta.

  • Przejdź do: Data collection > Hosts.
  • Wybierz host i kliknij kartę Encryption.

W poniższym przykładzie pola Issuer i Subject są wypełnione. Więcej informacji o tym, dlaczego i jak używać tych pól, znajdziesz w sekcji Ograniczanie dozwolonego wystawcy i podmiotu certyfikatu.

Zabbix web service

1. Przygotuj pliki z certyfikatami CA najwyższego poziomu, certyfikatem/łańcuchem certyfikatów Zabbix web service oraz kluczem prywatnym, zgodnie z opisem w sekcji Zabbix server. Następnie odpowiednio edytuj parametry TLSCAFile, TLSCertFile i TLSKeyFile w pliku konfiguracyjnym Zabbix web service.

2. Edytuj dodatkowy parametr TLS w pliku konfiguracyjnym Zabbix web service: TLSAccept=cert

Parametry TLS w końcowym pliku konfiguracyjnym web service mogą wyglądać następująco:

TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSCertFile=/home/zabbix/zabbix_web_service.crt
TLSKeyFile=/home/zabbix/zabbix_web_service.key

3. Skonfiguruj serwer Zabbix tak, aby łączył się z Zabbix web service skonfigurowanym pod kątem TLS, edytując parametr WebServiceURL w pliku konfiguracyjnym Zabbix server:

WebServiceURL=https://example.com:443/report

Ograniczanie dozwolonego wystawcy i podmiotu certyfikatu

Gdy dwa komponenty Zabbixa (na przykład serwer i agent) nawiązują połączenie TLS, wzajemnie weryfikują swoje certyfikaty. Jeśli certyfikat drugiej strony jest podpisany przez zaufane CA (z wcześniej skonfigurowanym certyfikatem najwyższego poziomu w TLSCAFile), jest ważny, nie wygasł i przechodzi inne kontrole, komunikacja między komponentami może być kontynuowana. W tym najprostszym przypadku wystawca certyfikatu i podmiot nie są weryfikowane.

Niesie to jednak ryzyko: każdy, kto ma ważny certyfikat, może podszyć się pod kogoś innego (na przykład certyfikat hosta może zostać użyty do podszycia się pod serwer). Choć może to być akceptowalne w małych środowiskach, w których certyfikaty są podpisywane przez dedykowane wewnętrzne CA, a ryzyko podszycia się jest niskie, w większych lub bardziej wrażliwych pod względem bezpieczeństwa środowiskach może to nie wystarczać.

Jeśli Twoje nadrzędne CA wystawia certyfikaty, które nie powinny być akceptowane przez Zabbixa, lub jeśli chcesz zmniejszyć ryzyko podszycia się, możesz ograniczyć dozwolone certyfikaty, określając ich wystawcę i podmiot.

Na przykład w pliku konfiguracyjnym proxy Zabbixa możesz podać:

TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com

Przy tych ustawieniach aktywny proxy nie będzie komunikować się z serwerem Zabbixa, którego certyfikat ma innego wystawcę lub inny podmiot. Podobnie pasywny proxy nie będzie akceptować żądań od takiego serwera.

Zasady dopasowywania ciągów Issuer i Subject

Zasady dopasowywania ciągów Issuer i Subject są następujące:

  • Ciągi Issuer i Subject są sprawdzane niezależnie. Oba są opcjonalne.
  • Niespecyfikowany ciąg oznacza, że akceptowany jest dowolny ciąg.
  • Ciągi są porównywane tak jak są i muszą być zgodne dokładnie.
  • Obsługiwane są znaki UTF-8. Nie są jednak obsługiwane symbole wieloznaczne (*) ani wyrażenia regularne.
  • Zaimplementowano następujące wymagania RFC 4514 - znaki wymagające poprzedzenia znakiem ucieczki (za pomocą odwrotnego ukośnika '\', U+005C):
    • w dowolnym miejscu ciągu: '"' (U+0022), '+' (U+002B), ',' (U+002C), ';' (U+003B), '<' (U+003C), '>' (U+003E), '\\' (U+005C);
    • na początku ciągu: spacja (' ', U+0020) lub znak numeru ('#', U+0023);
    • na końcu ciągu: spacja (' ', U+0020).
  • Znaki null (U+0000) nie są obsługiwane. Jeśli zostanie napotkany znak null, dopasowanie zakończy się niepowodzeniem.
  • Standardy RFC 4517 i RFC 4518 nie są obsługiwane.

Na przykład, jeśli ciągi organizacji (O) dla Issuer i Subject zawierają końcowe spacje, a ciąg jednostki organizacyjnej (OU) dla Subject zawiera podwójne cudzysłowy, znaki te muszą zostać poprzedzone znakiem ucieczki:

TLSServerCertIssuer=CN=Signing CA,OU=Development head,O=\ Example SIA\ ,DC=example,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group \"5\",O=\ Example SIA\ ,DC=example,DC=com
Kolejność i formatowanie pól

Zabbix stosuje zalecenia z RFC 4514, która określa "odwróconą" kolejność tych pól, zaczynając od pól najniższego poziomu (CN), przechodząc przez pola średniego poziomu (OU, O), a kończąc na polach najwyższego poziomu (DC).

TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com

Natomiast OpenSSL domyślnie wyświetla ciągi Issuer i Subject w kolejności od najwyższego do najniższego poziomu. W poniższym przykładzie pola Issuer i Subject zaczynają się od pola najwyższego poziomu (DC), a kończą na polu najniższego poziomu (CN). Formatowanie ze spacjami i separatorami pól również różni się w zależności od użytych opcji, dlatego nie będzie zgodne z formatem wymaganym przez Zabbix.

$ openssl x509 -noout -in /home/zabbix/zabbix_proxy.crt -issuer -subject
issuer= /DC=com/DC=zabbix/O=Zabbix SIA/OU=Development group/CN=Signing CA
subject= /DC=com/DC=zabbix/O=Zabbix SIA/OU=Development group/CN=Zabbix proxy

$ openssl x509 -noout -text -in /home/zabbix/zabbix_proxy.crt
Certificate:
    ...
        Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Signing CA
        ...
        Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Zabbix proxy

Aby poprawnie sformatować ciągi Issuer i Subject dla Zabbix, wywołaj OpenSSL z następującymi opcjami:

$ openssl x509 -noout -issuer -subject \
    -nameopt esc_2253,esc_ctrl,utf8,dump_nostr,dump_unknown,dump_der,sep_comma_plus,dn_rev,sname\
    -in /home/zabbix/zabbix_proxy.crt

Wynik będzie wtedy w odwrotnej kolejności, rozdzielany przecinkami i będzie można go użyć w plikach konfiguracyjnych Zabbix oraz frontend:

issuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
subject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com

Ograniczenia dotyczące używania rozszerzeń certyfikatów X.509 v3

Podczas implementowania certyfikatów X.509 v3 w Zabbix niektóre rozszerzenia mogą nie być w pełni obsługiwane lub mogą powodować niespójne zachowanie.

Rozszerzenie Subject Alternative Name

Zabbix nie obsługuje rozszerzenia Subject Alternative Name, które służy do określania alternatywnych nazw DNS, takich jak adresy IP lub adresy e-mail. Zabbix może zweryfikować wyłącznie wartość w polu Subject certyfikatu (zobacz Ograniczanie dozwolonego wystawcy i Subject certyfikatu). Jeśli certyfikaty zawierają pole subjectAltName, wynik weryfikacji certyfikatu może się różnić w zależności od konkretnych zestawów narzędzi kryptograficznych użytych do skompilowania komponentów Zabbix. W rezultacie Zabbix może zaakceptować lub odrzucić certyfikaty w zależności od tych kombinacji.

Rozszerzenie Extended Key Usage

Zabbix obsługuje rozszerzenie Extended Key Usage. Jeśli jednak jest ono używane, zazwyczaj wymagane jest określenie zarówno atrybutu clientAuth (dla uwierzytelniania klienta WWW TLS), jak i serverAuth (dla uwierzytelniania serwera WWW TLS). Na przykład:

  • W przypadku kontroli pasywnych, gdzie agent Zabbix działa jako serwer TLS, atrybut serverAuth musi być uwzględniony w certyfikacie agenta.
  • W przypadku kontroli aktywnych, gdzie agent działa jako klient TLS, atrybut clientAuth musi być uwzględniony w certyfikacie agenta.

Chociaż GnuTLS może zgłaszać ostrzeżenie dotyczące naruszeń użycia klucza, zazwyczaj pozwala na kontynuowanie komunikacji mimo tych ostrzeżeń.

Rozszerzenie Name Constraints

Obsługa rozszerzenia Name Constraints różni się w zależności od zestawu narzędzi kryptograficznych. Upewnij się, że wybrany zestaw narzędzi obsługuje to rozszerzenie. To rozszerzenie może uniemożliwić Zabbix wczytanie certyfikatów CA, jeśli ta sekcja jest oznaczona jako krytyczna, w zależności od używanego zestawu narzędzi.

Listy unieważnień certyfikatów (CRL)

Jeśli certyfikat zostanie skompromitowany, urząd certyfikacji (CA) może go unieważnić, dodając certyfikat do listy unieważnień certyfikatów (CRL). CRL są zarządzane za pomocą plików konfiguracyjnych i można je określić przy użyciu parametru TLSCRLFile w plikach konfiguracyjnych serwer, proxy i agent. Na przykład:

TLSCRLFile=/home/zabbix/zabbix_crl_file.crt

W tym przypadku plik zabbix_crl_file.crt może zawierać CRL z wielu CA i może wyglądać następująco:

-----BEGIN X509 CRL-----
MIIB/DCB5QIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixkARkWA2Nv
...
treZeUPjb7LSmZ3K2hpbZN7SoOZcAoHQ3GWd9npuctg=
-----END X509 CRL-----
-----BEGIN X509 CRL-----
MIIB+TCB4gIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQBGRYDY29t
...
CAEebS2CND3ShBedZ8YSil59O6JvaDP61lR5lNs=
-----END X509 CRL-----

Plik CRL jest wczytywany tylko podczas uruchamiania Zabbixa. Aby zaktualizować CRL, uruchom ponownie Zabbixa.

Jeśli komponenty Zabbixa są skompilowane z OpenSSL i używane są CRL, upewnij się, że każdy główny i pośredni CA w łańcuchach certyfikatów ma odpowiadającą mu CRL (nawet pustą) dołączoną w TLSCRLFile.

Rozwiązywanie problemów z certyfikatami

OpenSSL używany z CRL, a dla niektórego CA w łańcuchu certyfikatów jego CRL nie jest uwzględniony w TLSCRLFile

W dzienniku serwera TLS w przypadku peera OpenSSL:

failed to accept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1 returned error code 1: \
    file s3_srvr.c line 3251: error:14089086: SSL routines:ssl3_get_client_certificate:certificate verify failed: \
    TLS write fatal alert "unknown CA"

W dzienniku serwera TLS w przypadku peera GnuTLS:

failed to accept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1 returned error code 1: \
    file rsa_pk1.c line 103: error:0407006A: rsa routines:RSA_padding_check_PKCS1_type_1:\
    block type is not 01 file rsa_eay.c line 705: error:04067072: rsa routines:RSA_EAY_PUBLIC_DECRYPT:paddin
CRL wygasł lub wygasa podczas działania serwera

[OpenSSL]{.underline}, w logu serwera:

  • przed wygaśnięciem:
<!-- -->
cannot connect to proxy "proxy-openssl-1.0.1e": TCP successful, cannot establish TLS to [[127.0.0.1]:20004]:\
    SSL_connect() returned SSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086:\
    SSL routines:ssl3_get_server_certificate:certificate verify failed:\
    TLS write fatal alert "certificate revoked"
  • po wygaśnięciu:
<!-- -->
cannot connect to proxy "proxy-openssl-1.0.1e": TCP successful, cannot establish TLS to [[127.0.0.1]:20004]:\
    SSL_connect() returned SSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086:\
    SSL routines:ssl3_get_server_certificate:certificate verify failed:\
    TLS write fatal alert "certificate expired"

Chodzi o to, że przy prawidłowym CRL odwołany certyfikat jest zgłaszany jako "certificate revoked". Gdy CRL wygasa, komunikat o błędzie zmienia się na "certificate expired", co jest dość mylące.

[GnuTLS]{.underline}, w logu serwera:

  • przed i po wygaśnięciu tak samo:
<!-- -->
cannot connect to proxy "proxy-openssl-1.0.1e": TCP successful, cannot establish TLS to [[127.0.0.1]:20004]:\
      invalid peer certificate: The certificate is NOT trusted. The certificate chain is revoked.
Samopodpisany certyfikat, nieznany CA

[OpenSSL]{.underline}, w logu:

error:'self signed certificate: SSL_connect() set result code to SSL_ERROR_SSL: file ../ssl/statem/statem_clnt.c\
      line 1924: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:\
      TLS write fatal alert "unknown CA"'

Zaobserwowano to, gdy certyfikat serwera przez pomyłkę miał ten sam ciąg Issuer i Subject, mimo że został podpisany przez CA. Issuer i Subject są równe w głównym certyfikacie CA, ale nie mogą być równe w certyfikacie serwera. (To samo dotyczy certyfikatów proxy i agent.)

Aby sprawdzić, czy certyfikat zawiera te same wpisy Issuer i Subject, uruchom:

openssl x509 -in <yourcertificate.crt> -noout -text

Dopuszczalne jest, aby certyfikat główny (najwyższego poziomu) miał identyczne wartości Issuer i Subject.