EZD RP nie działa na Windows 10. Po zalogowaniu na Firefox, Edge, Chrome jest biały ekran, że się wczytuje. Wyczyszczona historia i ciasteczka i ustawiona prawidłowo godzina. Co można jeszcze zrobić?
EZD RP Wersja: 26.204.2 (B)
Sprawdź co jest w zakładce konsola, sieć włączając tryb developerski w przeglądarce.
OS nie powinien mieć znaczenia jeżeli masz najnowsze wersje przeglądarek obsługiwanych przez EZD RP.
Mam wszystkie przeglądarki aktualne. Działało w piątek a od poniedziałku już nie działa.
U nas dziś działa na win 10.
Na innych stanowiskach u mnie też działa z Win 10 a na tym konkretnym coś nie chce.
Proszę spróbować wyczyścić ciasteczka i pamięć podręczną witryny EZD
Nie pomaga czyszczenie ciasteczek i pamięci podręcznej witryny EZD
Zasady odsyłaczy: ignorowanie mniej ograniczonej zasady odsyłaczy „unsafe-url” w przypadku żądania między witrynami: https://stats.eadministracja.nask.pl/js/container_D5g0095B_p2_saas1_prod_de9e8aaf1124874366bec502.js container_D5g0095B_p2_saas1_prod_de9e8aaf1124874366bec502.js
OidcClient.readSigninResponseState: No matching state found in storage vendor.9e8ef18d3dc05bf6.js:251:1206324
UserManager.getUser: user not found in storage 2 vendor.9e8ef18d3dc05bf6.js:251:1206068
Error: No matching state found in storage
OidcClient https://ezdrp-web.p2.saas1.ezdrp.gov.pl/vendor.9e8ef18d3dc05bf6.js:251
taki błąd mam w EZD RP
Proszę spróbować odświeżyć stronę
Nawet testowa strona EZD RP też nie działa.
Dzień dobry,
może synchronizacja czasu 
Była różnica 30 min i jest już przestawiona prawidłowo.
Zacznę od zasady triażu: dokładny kod błędu w przeglądarce od razu wskazuje warstwę problemu:
ERR_CONNECTION_TIMED_OUT/ERR_CONNECTION_REFUSED→ warstwa sieciowa (firewall, VLAN, usługa nie słucha),ERR_NAME_NOT_RESOLVED→ DNS,NET::ERR_CERT_*(Chromium) /SEC_ERROR_*,MOZILLA_PKIX_ERROR_*(Firefox) → warstwa TLS/PKI.
Typowe problemy
1. Przesunięty zegar klienta (time skew)
Walidacja certyfikatu porównuje bieżący czas UTC z polami notBefore/notAfter — odchylenie poza okno ważności daje NET::ERR_CERT_DATE_INVALID, czyli ten sam kod co wygasły certyfikat. Dlatego zawsze najpierw zegar klienta, potem daty certu. Typowe źródła: padnięta bateria CMOS (czas „cofa się" po odcięciu zasilania), brak synchronizacji NTP, maszyny poza domeną.
Diagnostyka: w32tm /query /status (źródło i offset), timedatectl na Linuksie. Rozwiązanie: w domenie AD hierarchia czasu działa sama (klienci → DC, DC → PDC emulator) — pilnujesz tylko, żeby PDC miał zewnętrzne NTP:
w32tm /config /manualpeerlist:"tempus1.gum.gov.pl,0x9 tempus2.gum.gov.pl,0x9" /syncfromflags:manual /reliable:yes /update
w32tm /resync
Zegar cofający się po restarcie = wymiana CR2032, nie konfiguracja.
2. Brak zaufania do CA (certyfikaty własne)
Przeglądarka musi zbudować łańcuch do roota w swoim magazynie zaufania. Wewnętrzne CA / self-signed → NET::ERR_CERT_AUTHORITY_INVALID lub SEC_ERROR_UNKNOWN_ISSUER. Rozwiązanie systemowe to dystrybucja roota, nie klikanie wyjątków: GPO → Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities; ręcznie certutil -addstore -f Root ca.crt.
Dwie pułapki:
- Firefox ma własny magazyn NSS i domyślnie ignoruje magazyn Windows — potrzebna polityka
Certificates → ImportEnterpriseRoots: true(policies.json/ADMX) albosecurity.enterprise_roots.enabled = true. - Na Linuksie
update-ca-certificates(Debian/Void) załatwia curl/wget, ale Firefox/Chromium i tak używają NSS (certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "UrzadCA" -i ca.crt).
3. Certyfikat wygasł
Objaw jak w pkt 1 (NET::ERR_CERT_DATE_INVALID). Weryfikacja od strony serwera:
openssl s_client -connect host.local:443 -servername host.local </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
Doraźnie odnowienie, docelowo eliminacja przyczyny: autoenrollment z AD CS dla maszyn domenowych albo wewnętrzny ACME (step-ca od Smallstep + certbot/win-acme) oraz monitoring wygasania — Zabbix Agent 2 ma wbudowany item web.certificate.get, alert np. 21 dni przed terminem.
4. Certyfikat (lub ogniwo łańcucha) unieważniony
NET::ERR_CERT_REVOKED — ale tu jest więcej niuansów, niż się wydaje. Klient musi dosięgnąć CDP (CRL Distribution Point) lub respondera OCSP wpisanego w cert; CDP wyłącznie po LDAP nie zadziała dla urządzeń spoza domeny. Sama lista CRL ma też własny termin ważności (Next Update) — klasyczna awaria AD CS to żywe CA i nieopublikowana nowa CRL: wszystkie certy przestają przechodzić walidację w aplikacjach SChannel (CRYPT_E_REVOCATION_OFFLINE). Do tego przeglądarki zachowują się różnie: Chrome domyślnie nie odpytuje CRL/OCSP na żywo (CRLSets), Firefox robi OCSP soft-fail, a aplikacje Windows potrafią hard-failować — stąd objaw „w Chrome działa, w aplikacji nie".
Najlepsze narzędzie diagnostyczne: certutil -verify -urlfetch cert.cer — pokazuje cały łańcuch, osiągalność CDP/AIA/OCSP i status odwołania. Po stronie infrastruktury: publikacja CRL po HTTP, pilnowanie harmonogramu (certutil -crl).
Inne przyczyny:
5. Niekompletny łańcuch (brak intermediate). Serwer wysyła tylko leaf. Chromium/Windows często ratują się AIA fetching, Firefox tego nie robi → „działa w Edge, nie działa w Firefoksie". Diagnoza: openssl s_client -showcerts (czy serwer zwraca ≥2 certy, verify return code: 0). Fix: fullchain po stronie serwera.
6. Niezgodność nazwy (SAN). NET::ERR_CERT_COMMON_NAME_INVALID. Od Chrome 58 pole CN jest ignorowane — liczy się wyłącznie Subject Alternative Name. Wejście po IP albo krótkiej nazwie NetBIOS, gdy cert ma tylko FQDN, kończy się błędem. Fix: cert z kompletem SAN-ów, dla adresu wpis typu IP Address, nie DNS.
7. Negocjacja TLS. ERR_SSL_VERSION_OR_CIPHER_MISMATCH — stare urządzenia (karty zarządzające UPS, iDRAC, drukarki, rejestratory CCTV) umieją tylko TLS 1.0/1.1, których współczesne przeglądarki nie akceptują. Diagnoza: openssl s_client -tls1_2 vs -tls1. Docelowo reverse proxy (nginx) terminujący nowoczesny TLS przed zabytkiem, zamiast osłabiania przeglądarek.
8. HSTS. Jeśli witryna kiedykolwiek wysłała Strict-Transport-Security, przy błędzie certyfikatu przeglądarka nie pokaże przycisku „przejdź mimo to". Czyszczenie wpisu: chrome://net-internals/#hsts → Delete domain security policies.
9. DNS / DoH. Poza klasyką (zły DNS na końcówce) współczesna pułapka: DNS over HTTPS w przeglądarce omija wewnętrzny DNS i pyta Cloudflare/Google, które nie znają Twoich nazw wewnętrznych. Fix: polityki DnsOverHttps (Chromium) / DNSOverHTTPS (Firefox) przez GPO, ewentualnie domena kanarkowa use-application-dns.net na wewnętrznym DNS.
10. Inspekcja TLS po drodze. AV/UTM podmieniający certyfikaty — u Ciebie kandydatem byłby Bitdefender GravityZone z modułem skanowania ruchu szyfrowanego. Objaw: issuer w przeglądarce to nie Twoja CA. Fix: wyjątek dla hostów wewnętrznych albo dystrybucja CA inspektora.
Kolejność diagnozy na końcówce:
- Odczytaj dokładny kod błędu (klik w „Zaawansowane" / kłódkę).
Test-NetConnection host -Port 443— odetnij warstwę sieciową.w32tm /query /status— zegar.openssl s_client/certutil -verify -urlfetch— PKI od strony klienta.- Test krzyżowy: inna przeglądarka, tryb prywatny, druga końcówka — izoluje problem klienta od problemu serwera.