Dažniausios SSL problemos ir jų sprendimas

Dažniausios SSL problemos ir jų sprendimas: 25 klaidų diagnostika

Autorius /

SSL sertifikatas yra viena tų technologijų, kuri arba veikia, arba visiškai blokuoja jūsų svetainę. Tarpinio varianto nėra. Kai lankytojas pamato raudoną naršyklės įspėjimą, jis neanalizuoja priežasčių, tiesiog spaudžia „Atgal” ir eina pas konkurentą.

Geroji pusė: absoliuti dauguma SSL problemų turi aiškias priežastis ir konkrečius sprendimus. Šiame vadove rasite 25 dažniausias SSL klaidas, sugrupuotas pagal tipą, su diagnostikos komandomis ir tiksliais taisymo žingsniais.

Kaip skaityti SSL klaidos pranešimus

Prieš gilinantis į konkrečias problemas, verta suprasti, kaip naršyklės praneša apie SSL klaidas.

Chrome klaidų formatai

Chrome naudoja formatą NET::ERR_ su konkrečiu klaidos kodu. Kiekvienas kodas nurodo skirtingą problemos tipą:

  • ERR_CERT_ prefiksas: problema su pačiu sertifikatu (galiojimas, grandinė, domeno vardas)
  • ERR_SSL_ prefiksas: problema su SSL/TLS protokolu arba konfigūracija
  • ERR_CONNECTION_ prefiksas: problema užmezgant ryšį su serveriu

Firefox klaidų formatai

Firefox naudoja savo klaidų kodus ir dažnai pateikia išsamesnį paaiškinimą nei Chrome:

  • SEC_ERROR_ prefiksas: saugumo klaidos
  • SSL_ERROR_ prefiksas: SSL protokolo klaidos
  • MOZILLA_PKIX_ERROR_ prefiksas: sertifikato validacijos klaidos

Diagnostikos pradžia

Prieš taisydami bet kokią SSL klaidą, surinkite pagrindinę informaciją:

# 1. Patikrinkite, ar serveris atsako 443 portu
openssl s_client -connect jusudomenas.lt:443 \
  -servername jusudomenas.lt 2>&1 | head -30

# 2. Patikrinkite sertifikato datas
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -dates -subject -issuer

# 3. Patikrinkite sertifikatų grandinę
openssl s_client -connect jusudomenas.lt:443 \
  -servername jusudomenas.lt -showcerts 2>/dev/null | \
  grep -E "^(Certificate chain| [0-9]+ s:|   i:)"

# 4. Patikrinkite TLS versiją ir šifravimą
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  grep -E "Protocol|Cipher"

Šios keturios komandos per kelias sekundes parodys, ar sertifikatas galioja, ar grandinė pilna, ir kokia TLS konfigūracija naudojama. Remiantis šiais duomenimis, galėsite greitai identifikuoti problemą.

1 kategorija: sertifikato galiojimo problemos

Problema #1: NET::ERR_CERT_DATE_INVALID (sertifikatas pasibaigęs)

Ką mato lankytojas: Pilno ekrano Chrome įspėjimas „Your connection is not private” su kodu NET::ERR_CERT_DATE_INVALID. Firefox rodo „Warning: Potential Security Risk Ahead” su kodu SEC_ERROR_EXPIRED_CERTIFICATE.

Priežastys:

  1. Sertifikato galiojimas baigėsi. Tai dažniausia priežastis. Let’s Encrypt sertifikatai galioja 90 dienų, mokamų sertifikatų maksimalus terminas yra 398 dienos.
  2. Sertifikato galiojimas dar neprasidėjo. Rečiau, bet pasitaiko, jei sertifikatas buvo įdiegtas prieš jo „Not Before” datą.
  3. Serverio laikrodis rodo neteisingą laiką. Jei serverio sistemos laikas yra praeityje arba ateityje, TLS handshake gali nepavykti, net jei sertifikatas iš tikrųjų galioja.
  4. Kliento kompiuterio laikas neteisingas. Jei lankytojo kompiuterio laikrodis rodo blogą datą, naršyklė manys, kad sertifikatas pasibaigęs. Tai nėra serverio problema, bet verta žinoti diagnoztikos tikslais.

Diagnostika:

# Patikrinkite sertifikato datas
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -dates

# Kiek dienų liko (arba kiek dienų praėjo nuo pabaigos)
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -enddate | \
  awk -F= '{
    cmd = "date -d \""$2"\" +%s"; cmd | getline exp; close(cmd);
    cmd = "date +%s"; cmd | getline now; close(cmd);
    days = int((exp - now) / 86400);
    if (days >= 0) print "Liko " days " dienų";
    else print "Pasibaigęs prieš " (-days) " dienų";
  }'

# Patikrinkite serverio laiką
date
timedatectl status

Sprendimas (Let’s Encrypt):

# Pabandykite atnaujinti sertifikatą
sudo certbot renew

# Jei atnaujinimas nepavyksta, priverstinai atnaujinkite
sudo certbot renew --force-renewal

# Jei Certbot sugadintas, gaukite naują sertifikatą
sudo certbot certonly --nginx -d jusudomenas.lt -d www.jusudomenas.lt

# Perkraukite žiniatinklio serverį
sudo systemctl reload nginx
# arba
sudo systemctl reload apache2

Sprendimas (mokamas sertifikatas):

  1. Prisijunkite prie sertifikato tiekėjo arba perpardavėjo valdymo pulto.
  2. Atnaujinkite sertifikatą (renew). Dauguma tiekėjų leidžia tai padaryti prieš galiojimo pabaigą.
  3. Sugeneruokite naują CSR (jei reikalauja tiekėjas).
  4. Atsisiųskite naują sertifikatą ir CA Bundle.
  5. Pakeiskite senus failus serveryje naujais.
  6. Perkraukite žiniatinklio serverį.

Sprendimas (serverio laikrodis):

# Sinchronizuokite laiką
sudo timedatectl set-ntp true

# Arba rankiniu būdu
sudo ntpdate pool.ntp.org

# Patikrinkite laiko zoną
sudo timedatectl set-timezone Europe/Vilnius

Prevencija:

  • Nustatykite automatinį atnaujinimą (Certbot cron arba systemd timer)
  • Nustatykite stebėjimo pranešimus 30 dienų prieš galiojimo pabaigą
  • Patikrinkite automatinio atnaujinimo veikimą: sudo certbot renew --dry-run

Problema #2: Certbot automatinis atnaujinimas neveikia

Simptomai: Sertifikatas pasibaigė, nors Certbot buvo sukonfigūruotas automatiniam atnaujinimui.

Dažniausios priežastys ir sprendimai:

Priežastis A: Certbot timer/cron neaktyvus

# Patikrinkite systemd timer
sudo systemctl status certbot.timer

# Jei neaktyvus, aktyvuokite
sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer

# Patikrinkite cron (jei nenaudojate systemd)
sudo crontab -l | grep certbot

Priežastis B: 80 portas užblokuotas

Let’s Encrypt HTTP-01 validacija reikalauja, kad serveris atsakytų 80 portu. Jei ugniasienė blokuoja 80 portą, atnaujinimas nepavyksta.

# Patikrinkite, ar 80 portas atidarytas
sudo ufw status | grep 80
sudo iptables -L -n | grep 80

# Atidarykite 80 portą
sudo ufw allow 80

Priežastis C: Žiniatinklio serverio konfigūracija pasikeitė

Jei pakeitėte Nginx arba Apache konfigūraciją po pradinio Certbot diegimo, Certbot gali nebegalėti pasiekti .well-known/acme-challenge katalogo.

# Patikrinkite, ar ACME challenge kelias pasiekiamas
curl -I http://jusudomenas.lt/.well-known/acme-challenge/test

# Jei grąžina 404, pridėkite location bloką Nginx konfigūracijoje
# location /.well-known/acme-challenge/ {
#     root /var/www/html;
# }

Priežastis D: Domenas nebenukreiptas į serverį

Jei pakeitėte DNS A įrašą ar pradėjote naudoti CDN (Cloudflare), HTTP-01 validacija gali nepavykti, nes užklausos eina ne į jūsų serverį.

# Patikrinkite, kur nukreiptas domenas
dig +short jusudomenas.lt

# Jei naudojate Cloudflare, apsvarstykite DNS-01 validaciją
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d jusudomenas.lt -d "*.jusudomenas.lt"

Priežastis E: Certbot versija pasenusi

# Patikrinkite Certbot versiją
certbot --version

# Atnaujinkite Certbot
sudo apt update && sudo apt upgrade certbot python3-certbot-nginx

Problema #3: Sertifikatas galioja, bet naršyklė rodo neteisingą sertifikatą

Simptomai: Jūsų svetainė turi galiojantį sertifikatą, tačiau naršyklė rodo kitos svetainės arba serverio numatytąjį sertifikatą.

Priežastis: SNI (Server Name Indication) konfigūracijos problema. Kai viename IP adrese veikia keli domenai, serveris turi žinoti, kurį sertifikatą pateikti kiekvienam domenui. Jei SNI nesukonfigūruotas teisingai, serveris pateikia numatytąjį (default) sertifikatą.

Diagnostika:

# Patikrinkite, koks sertifikatas grąžinamas
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -subject

# Palyginkite su numatytuoju (be servername)
echo | openssl s_client \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -subject

Jei rezultatai skiriasi, SNI konfigūracija yra problema.

Sprendimas (Nginx):

Kiekvienas domenas turi turėti atskirą server bloką su savo ssl_certificate ir ssl_certificate_key direktyvomis:

# jusudomenas.lt
server {
    listen 443 ssl http2;
    server_name jusudomenas.lt www.jusudomenas.lt;
    ssl_certificate /etc/ssl/certs/jusudomenas.lt.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/jusudomenas.lt.key;
    # ...
}

# kitasdomenas.lt
server {
    listen 443 ssl http2;
    server_name kitasdomenas.lt www.kitasdomenas.lt;
    ssl_certificate /etc/ssl/certs/kitasdomenas.lt.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/kitasdomenas.lt.key;
    # ...
}

Taip pat patikrinkite, ar neturite default_server su neteisingu sertifikatu:

# Numatytasis serverio blokas, kuris atmeta užklausas be tinkamo domeno
server {
    listen 443 ssl http2 default_server;
    server_name _;
    ssl_certificate /etc/ssl/certs/default.pem;
    ssl_certificate_key /etc/ssl/private/default.key;
    return 444;  # Uždaryti ryšį be atsakymo
}

Sprendimas (Apache):

Įsitikinkite, kad kiekvienas VirtualHost turi teisingą ServerName ir savo sertifikato failus:

<VirtualHost *:443>
    ServerName jusudomenas.lt
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/jusudomenas.lt.crt
    SSLCertificateKeyFile /etc/ssl/private/jusudomenas.lt.key
    SSLCertificateChainFile /etc/ssl/certs/jusudomenas.lt.ca-bundle.crt
</VirtualHost>

2 kategorija: sertifikatų grandinės problemos

Problema #4: ERR_CERT_AUTHORITY_INVALID (nepasitikimas sertifikatu)

Ką mato lankytojas: Chrome: „Your connection is not private” su kodu NET::ERR_CERT_AUTHORITY_INVALID. Firefox: SEC_ERROR_UNKNOWN_ISSUER.

Priežastys:

  1. Trūksta tarpinių sertifikatų (CA Bundle). Tai pati dažniausia šios klaidos priežastis. Serveris siunčia tik domeno sertifikatą, bet ne tarpinę grandinę.
  2. Sertifikatas pasirašytas netinkamai (self-signed). Jei naudojate savo pasirašytą sertifikatą, naršyklės jo nepripažins.
  3. Šakninis sertifikatas nebepripažįstamas. Retais atvejais sertifikavimo institucijos šakninis sertifikatas gali būti pašalintas iš naršyklių pasitikėjimo sąrašo.

Diagnostika:

# Patikrinkite grandinę
openssl s_client -connect jusudomenas.lt:443 \
  -servername jusudomenas.lt 2>&1 | \
  grep -E "verify error|verify return|depth"

# Jei matote:
# verify error:num=21:unable to verify the first certificate
# tai reiškia, kad trūksta tarpinių sertifikatų

# Parodykite pilną grandinę
openssl s_client -connect jusudomenas.lt:443 \
  -servername jusudomenas.lt -showcerts 2>/dev/null | \
  grep "s:" | head -5

Sprendimas (trūkstama grandinė, Nginx):

# 1. Atsisiųskite tarpinį sertifikatą iš savo CA
# Let's Encrypt: paprastai Certbot tai padaro automatiškai
# Mokamas: atsisiųskite CA Bundle iš tiekėjo svetainės

# 2. Sukurkite pilną grandinės failą
cat jusudomenas.lt.crt tarpinis.crt > fullchain.pem

# 3. Atnaujinkite Nginx konfigūraciją
# ssl_certificate /etc/ssl/certs/fullchain.pem;
# (ne atskiras domeno sertifikatas!)

# 4. Perkraukite Nginx
sudo nginx -t && sudo systemctl reload nginx

Sprendimas (trūkstama grandinė, Apache):

# Apache naudoja atskirą direktyvą tarpinei grandinei
# SSLCertificateFile /etc/ssl/certs/jusudomenas.lt.crt
# SSLCertificateChainFile /etc/ssl/certs/ca-bundle.crt

# Patikrinkite ir perkraukite
sudo apachectl configtest && sudo systemctl reload apache2

Sprendimas (self-signed sertifikatas):

Self-signed sertifikatai tinka tik vidinėms sistemoms ir testavimui. Viešai prieinamoms svetainėms naudokite Let’s Encrypt arba mokamą sertifikatą:

sudo certbot --nginx -d jusudomenas.lt -d www.jusudomenas.lt

Kaip rasti teisingą CA Bundle:

Jei nežinote, koks CA Bundle reikalingas jūsų sertifikatui:

  1. Atidarykite sertifikato failą ir raskite „Issuer” lauką.
  2. Ieškokite tarpinio sertifikato pagal Issuer pavadinimą sertifikato tiekėjo svetainėje.
  3. Arba naudokite whatsmychaincert.com, kuris automatiškai nustato trūkstamus grandinės narius.

Problema #5: SSL grandinės tvarka neteisinga

Simptomai: SSL Labs rodo „Chain issues: Contains incorrect order”. Kai kurie senesni klientai (Android 4.x, Windows XP) negali prisijungti.

Priežastis: Sertifikatų grandinės failas turi neteisingą tvarką. Teisingą tvarka yra: domeno sertifikatas → tarpinis sertifikatas → (šakninis sertifikatas, nebūtinas).

Diagnostika:

# Parodykite grandinės tvarką
openssl s_client -connect jusudomenas.lt:443 \
  -servername jusudomenas.lt -showcerts 2>/dev/null | \
  grep -E "^ [0-9]+ s:|   i:"

# Teisingas rezultatas:
# 0 s:CN = jusudomenas.lt         (jūsų domenas)
#   i:CN = R3                      (tarpinis CA)
# 1 s:CN = R3                      (tarpinis CA)
#   i:CN = ISRG Root X1            (šakninis CA)

Jei tvarka atvirkštinė (šakninis pirmas, domeno paskutinis), turite ją pataisyti.

Sprendimas:

# Teisingas sujungimas: domeno sertifikatas pirmas
cat jusudomenas.lt.crt intermediate.crt > fullchain.pem

# NETEISINGAS sujungimas (nedarykite taip):
# cat intermediate.crt jusudomenas.lt.crt > fullchain.pem

Problema #6: Šakninis sertifikatas įtrauktas į grandinę (nereikalingas)

Simptomai: SSL Labs rodo „Chain issues: Contains anchor”. Viskas veikia, bet grandinė yra didesnė nei reikėtų, kas šiek tiek sulėtina TLS handshake.

Priežastis: Serveris siunčia ir šakninį (root) sertifikatą, kuris jau yra naršyklės pasitikėjimo saugykloje. Tai nėra klaida, bet nereikalingas trafiko švaistymasis.

Sprendimas:

Pašalinkite šakninį sertifikatą iš grandinės failo. Palikite tik domeno sertifikatą ir tarpinius sertifikatus:

# Grandinėje turėtų būti tik:
# 1. Jūsų domeno sertifikatas
# 2. Tarpinis sertifikatas (-ai)
# BEZ šakninio sertifikato

cat jusudomenas.lt.crt intermediate.crt > fullchain.pem
# Neįtraukite root.crt

3 kategorija: domeno vardo problemos

Problema #7: NET::ERR_CERT_COMMON_NAME_INVALID

Ką mato lankytojas: Chrome rodo „Your connection is not private” su kodu NET::ERR_CERT_COMMON_NAME_INVALID. Firefox: SSL_ERROR_BAD_CERT_DOMAIN.

Priežastys:

  1. Sertifikatas išduotas kitam domenui. Pavyzdžiui, sertifikatas yra www.jusudomenas.lt, bet lankytojas bando pasiekti jusudomenas.lt (be www).
  2. Subdomenas neįtrauktas į sertifikatą. Sertifikatas apima jusudomenas.lt, bet ne shop.jusudomenas.lt.
  3. Wildcard sertifikatas neapima pagrindinio domeno. *.jusudomenas.lt apima subdomenus, bet ne patį jusudomenas.lt (priklausomai nuo sertifikatų tiekėjo, dažniausiai apima abu, bet ne visada).
  4. IP adresas naudojamas vietoj domeno vardo. Sertifikatas išduotas domeno vardui, bet lankytojas bando prisijungti per IP adresą.

Diagnostika:

# Patikrinkite, kokie domenai nurodyti sertifikate
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -text | \
  grep -A2 "Subject Alternative Name"

# Rezultatas:
# DNS:jusudomenas.lt, DNS:www.jusudomenas.lt

Jei reikiamo domeno nėra sąraše, sertifikatas turi būti pergeneruotas.

Sprendimas (Let’s Encrypt):

# Pergeneruokite sertifikatą su visais reikiamais domenais
sudo certbot --nginx \
  -d jusudomenas.lt \
  -d www.jusudomenas.lt \
  -d shop.jusudomenas.lt \
  -d blog.jusudomenas.lt

# Arba naudokite Wildcard
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d jusudomenas.lt -d "*.jusudomenas.lt"

Sprendimas (mokamas sertifikatas):

  1. Kreipkitės į sertifikato tiekėją dėl pergeneravimo (reissue).
  2. Sugeneruokite naują CSR su SAN (Subject Alternative Names), įtraukiančiu visus reikiamus domenus.
  3. Dauguma tiekėjų leidžia pergeneruoti nemokamai galiojimo laikotarpiu.

Problema #8: Sertifikatas neveikia su www arba be www versija

Simptomai: https://jusudomenas.lt veikia, bet https://www.jusudomenas.lt rodo klaidą (arba atvirkščiai).

Priežastis: Sertifikatas neapima vieno iš variantų (su www arba be www).

Diagnostika:

# Patikrinkite SAN įrašus
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -ext subjectAltName

echo | openssl s_client -servername www.jusudomenas.lt \
  -connect www.jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -ext subjectAltName

Sprendimas:

# Let's Encrypt: visada įtraukite abu variantus
sudo certbot --nginx -d jusudomenas.lt -d www.jusudomenas.lt

Be to, nustatykite peradresavimą, kad vienas variantas nukreiptų į kitą:

# Peradresavimas: www → be www
server {
    listen 443 ssl http2;
    server_name www.jusudomenas.lt;
    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;
    return 301 https://jusudomenas.lt$request_uri;
}

4 kategorija: TLS protokolo ir šifravimo problemos

Problema #9: ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Ką mato lankytojas: Chrome: ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Firefox: SSL_ERROR_NO_CYPHER_OVERLAP.

Priežastys:

  1. Serveris palaiko tik labai senus protokolus. Jei serveris siūlo tik SSLv3 ar TLS 1.0, šiuolaikinės naršyklės atsisakys jungtis.
  2. Serveris siūlo tik šifravimo algoritmus, kurių naršyklė nepalaiko. Tai retesnė situacija, bet gali pasitaikyti su labai specifine konfigūracija.
  3. Sertifikatas naudoja seną arba silpną raktų ilgį. RSA raktai trumpesni nei 2048 bitų yra atmetami.
  4. Sertifikatas naudoja SHA-1 maišos funkciją. SHA-1 yra pasenusi ir nepriimama šiuolaikinių naršyklių.

Diagnostika:

# Patikrinkite, kokius protokolus ir šifrus siūlo serveris
echo | openssl s_client -connect jusudomenas.lt:443 \
  -servername jusudomenas.lt 2>/dev/null | \
  grep -E "Protocol|Cipher"

# Patikrinkite sertifikato rakto ilgį
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -text | grep "Public-Key"

# Patikrinkite maišos algoritmą
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 2>/dev/null | \
  openssl x509 -noout -text | grep "Signature Algorithm"

Sprendimas (Nginx):

# Pašalinkite senus protokolus ir silpnus šifrus
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

Sprendimas (Apache):

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off

Jei problema yra SHA-1 arba trumpas RSA raktas, reikės sugeneruoti naują sertifikatą su RSA 2048+ bitų ir SHA-256 maiša.

Problema #10: ERR_SSL_PROTOCOL_ERROR

Ką mato lankytojas: Chrome: ERR_SSL_PROTOCOL_ERROR. Svetainė visiškai nepasiekiama per HTTPS.

Priežastys:

  1. SSL modulis neaktyvuotas žiniatinklio serveryje.
  2. 443 portas neuž klausomas serveryje.
  3. Ugniasienė blokuoja 443 portą.
  4. Sertifikato arba privataus rakto failas sugadintas.
  5. Nginx/Apache konfigūracijos klaida trukdo paleisti SSL.

Diagnostika:

# Patikrinkite, ar serveris klausosi 443 porto
sudo netstat -tlnp | grep 443
# arba
sudo ss -tlnp | grep 443

# Patikrinkite ugniasienę
sudo ufw status | grep 443
sudo iptables -L -n | grep 443

# Patikrinkite žiniatinklio serverio konfigūraciją
sudo nginx -t
# arba
sudo apachectl configtest

# Patikrinkite, ar sertifikato ir rakto failai egzistuoja ir skaitomi
sudo ls -la /etc/ssl/certs/fullchain.pem
sudo ls -la /etc/ssl/private/privkey.pem

Sprendimas (kiekvienos priežasties atveju):

# 1. Aktyvuokite SSL modulį (Apache)
sudo a2enmod ssl
sudo systemctl restart apache2

# 2. Atidarykite 443 portą
sudo ufw allow 443/tcp

# 3. Patikrinkite ir ištaisykite konfigūraciją
sudo nginx -t  # Parodys tikslią klaidos eilutę
sudo systemctl reload nginx

# 4. Patikrinkite failų vientisumą
openssl x509 -in /etc/ssl/certs/fullchain.pem -noout -text > /dev/null
openssl rsa -in /etc/ssl/private/privkey.pem -noout -check

Problema #11: SSL handshake nepavyksta (ERR_SSL_HANDSHAKE_ERROR / SSL_ERROR_HANDSHAKE_FAILURE_ALERT)

Priežastys:

  1. Privatus raktas nesutampa su sertifikatu.
  2. Sertifikato failas sugadintas (pvz., neteisingas kodavimas, trūksta dalies turinio).
  3. Serverio atminties trūkumas (retai, bet didelio srauto serveriuose gali trūkti atminties SSL sesijoms).

Diagnostika:

# Patikrinkite, ar privatus raktas atitinka sertifikatą
openssl x509 -noout -modulus -in sertifikatas.crt | openssl md5
openssl rsa -noout -modulus -in privatusraktas.key | openssl md5
# Abu MD5 hash'ai TURI sutapti

# Patikrinkite sertifikato failą
openssl x509 -in sertifikatas.crt -noout -text > /dev/null
# Jei rodo klaidą, failas sugadintas

# Patikrinkite privataus rakto failą
openssl rsa -in privatusraktas.key -noout -check
# Tikėtinas: "RSA key ok"

Sprendimas (nesutampantis raktas):

Jei privatus raktas nesutampa su sertifikatu, turite sugeneruoti naują CSR su nauju privačiu raktu ir pergeneruoti sertifikatą:

# Naujas CSR ir raktas
openssl req -new -newkey rsa:2048 -nodes \
  -keyout naujas.key -out naujas.csr

# Pateikite naują CSR sertifikato tiekėjui (reissue)
# Arba Let's Encrypt:
sudo certbot certonly --nginx -d jusudomenas.lt -d www.jusudomenas.lt

5 kategorija: mixed content problemos

Problema #12: spynelė nerodoma (Mixed Content)

Simptomai: SSL sertifikatas galioja, HTTPS veikia, bet naršyklė nerodo spynelės piktogramos. Vietoj to rodomas pilkas trikampis arba informacijos piktograma.

Priežastis: HTTPS puslapis kraunama resursus (paveikslėlius, CSS, JavaScript, šriftus) per nešifruotą HTTP ryšį.

Diagnostika:

# Greitai raskite HTTP resursus puslapio HTML kode
curl -s https://jusudomenas.lt | \
  grep -oiE '(src|href|action|url)\s*=\s*["\x27]http://[^"\x27]*["\x27]' | \
  sort -u

# Patikrinkite CSS failus
curl -s https://jusudomenas.lt/style.css | \
  grep -oiE 'url\s*\(\s*["\x27]?http://[^"\x27)]*' | \
  sort -u

Naršyklės konsolėje (F12 → Console) matysite tikslų pranešimą su kiekvieno probleminio resurso URL.

Sprendimas pagal resurso tipą:

Vidiniai paveikslėliai ir failai:

# WordPress: search-replace duomenų bazėje
wp search-replace 'http://jusudomenas.lt' 'https://jusudomenas.lt' \
  --all-tables --precise

# Statinė svetainė: pakeiskite visuose failuose
find /var/www/jusudomenas.lt/ \
  \( -name "*.html" -o -name "*.css" -o -name "*.js" -o -name "*.php" \) \
  -exec sed -i 's|http://jusudomenas.lt|https://jusudomenas.lt|g' {} +

Išoriniai resursai:

<!-- Pakeiskite http:// į https:// -->
<script src="https://cdn.example.com/library.js"></script>

<!-- Arba naudokite protokolo santykinį URL -->
<script src="//cdn.example.com/library.js"></script>

CSS failuose:

/* Pakeiskite */
background-image: url('https://jusudomenas.lt/images/fonas.jpg');

/* Arba santykiniu keliu */
background-image: url('/images/fonas.jpg');

Inline JavaScript:

// Pakeiskite užkoduotus HTTP URL
// Buvo:
var apiUrl = 'http://jusudomenas.lt/api/';
// Tapo:
var apiUrl = 'https://jusudomenas.lt/api/';

// Arba dinamiškai:
var apiUrl = window.location.protocol + '//jusudomenas.lt/api/';

Problema #13: Mixed content iš trečiųjų šalių paslaugų

Simptomai: Jūsų svetainės vidinis turinys yra HTTPS, bet trečiųjų šalių widgetai ar skriptai kraunami per HTTP.

Dažniausi kaltininkai:

  • Seni Google Fonts embed kodai (jau seniai palaikantys HTTPS, bet seni embed kodai gali turėti HTTP)
  • Reklaminiai tinklai
  • Socialinių tinklų widgetai (seni embed kodai)
  • Pokalbių (chat) widgetai
  • Analitikos skriptai
  • Iframe embeds (YouTube, Google Maps seni kodai)

Sprendimas:

  1. Patikrinkite, ar trečiosios šalies paslauga palaiko HTTPS (beveik visos šiuolaikinės paslaugos palaiko).
  2. Pakeiskite http:// į https:// embed kode.
  3. Jei trečioji šalis nepalaiko HTTPS, apsvarstykite jos atsisakymą arba resursų talpinimą savo serveryje (jei licencija leidžia).

Problema #14: Content-Security-Policy blokuoja resursus

Simptomai: Resursai nėra kraunami, nors jie naudoja HTTPS. Konsolėje matomas „Refused to load” pranešimas su CSP nuoroda.

Priežastis: Content-Security-Policy antraštė riboja, iš kur galima krauti resursus. Jei CSP politika per griežta arba neapima reikiamų domenų, resursai blokuojami.

Diagnostika:

# Patikrinkite CSP antraštę
curl -sI https://jusudomenas.lt | grep -i "content-security-policy"

Sprendimas:

Peržiūrėkite CSP politiką ir pridėkite trūkstamus domenus:

# Nginx pavyzdys
add_header Content-Security-Policy "
  default-src 'self' https:;
  script-src 'self' https://cdn.example.com https://www.google-analytics.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' https: data:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.example.com;
" always;

6 kategorija: peradresavimo problemos

Problema #15: ERR_TOO_MANY_REDIRECTS (peradresavimo kilpa)

Ką mato lankytojas: Naršyklė rodo „This page isn’t working. jusudomenas.lt redirected you too many times.”

Priežastys:

  1. Cloudflare „Flexible” SSL + serverio HTTPS peradresavimas. Tai pati dažniausia šios klaidos priežastis. Cloudflare „Flexible” režimas jungiasi prie jūsų serverio per HTTP. Jūsų serveris mato HTTP užklausą ir bando peradresuoti į HTTPS. Cloudflare vėl siunčia užklausą per HTTP. Ir taip be galo.
  2. Dvigubas peradresavimas. .htaccess peradresavimas + WordPress įskiepis (pvz., Really Simple SSL) abu bando peradresuoti.
  3. WordPress siteurl nustatytas su HTTPS, bet SSL neveikia. WordPress generuoja HTTPS nuorodas, serveris peradresuoja atgal į HTTP, WordPress vėl į HTTPS.
  4. CDN ir serverio peradresavimo konfliktas.

Diagnostika:

# Peržiūrėkite peradresavimo grandinę
curl -I -L --max-redirs 10 http://jusudomenas.lt 2>&1 | \
  grep -E "HTTP/|Location:"

# Jei matote besikartojantį peradresavimą:
# HTTP/1.1 301 Moved Permanently
# Location: https://jusudomenas.lt/
# HTTP/1.1 301 Moved Permanently
# Location: http://jusudomenas.lt/
# ... ir taip toliau

Sprendimas (Cloudflare):

1. Cloudflare → SSL/TLS → Overview
2. Pakeiskite režimą iš "Flexible" į "Full" arba "Full (Strict)"
3. "Full (Strict)" reikalauja galiojančio sertifikato jūsų serveryje

Jei negalite pakeisti Cloudflare režimo, pakeiskite serverio peradresavimo logiką:

# .htaccess - tikrinkite X-Forwarded-Proto vietoj HTTPS
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Sprendimas (WordPress peradresavimo kilpa):

// wp-config.php - pridėkite prieš "That's all, stop editing!"

// Jei naudojate reverse proxy arba Cloudflare
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Sprendimas (dvigubas peradresavimas):

Pasirinkite VIENĄ peradresavimo metodą ir pašalinkite kitus:

  • .htaccess peradresavimas (rekomenduojama)
  • ARBA WordPress įskiepis (Really Simple SSL)
  • ARBA Nginx konfigūracija
  • Niekada ne du ar trys vienu metu

Problema #16: Peradresavimas iš HTTPS atgal į HTTP

Simptomai: Įvedus https://jusudomenas.lt, naršyklė peradresuoja atgal į http://jusudomenas.lt.

Priežastys:

  1. .htaccess turi HTTP peradresavimą. Sena .htaccess taisyklė gali nukreipti visą srautą į HTTP.
  2. WordPress siteurl nustatytas su HTTP. Jei WordPress nustatymuose vis dar yra http://, WordPress generuos HTTP peradresavimus.
  3. Serverio konfigūracijoje yra klaida.

Diagnostika:

# Patikrinkite peradresavimą
curl -I https://jusudomenas.lt

# Jei matote:
# HTTP/1.1 301 Moved Permanently
# Location: http://jusudomenas.lt/
# tai reiškia, kad serveris aktyviai nukreipia iš HTTPS į HTTP

Sprendimas:

# Patikrinkite .htaccess
cat /var/www/jusudomenas.lt/.htaccess

# Ieškokite taisyklių, kurios nukreipia į HTTP
# Pavyzdžiui:
# RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [L,R=301]
# Pakeiskite http:// į https://

# WordPress: patikrinkite duomenų bazę
wp option get siteurl
wp option get home
# Jei rodo http://, pakeiskite:
wp option update siteurl 'https://jusudomenas.lt'
wp option update home 'https://jusudomenas.lt'

Problema #17: 301 peradresavimas neperduoda URL struktūros

Simptomai: http://jusudomenas.lt/straipsnis/pavadinimas/ peradresuoja į https://jusudomenas.lt/ (pagrindinį puslapį), o ne į https://jusudomenas.lt/straipsnis/pavadinimas/.

Priežastis: Peradresavimo taisyklė neišsaugo originalaus URL kelio.

Diagnostika:

curl -I http://jusudomenas.lt/straipsnis/pavadinimas/
# Jei Location rodo tik https://jusudomenas.lt/ be kelio -
# peradresavimo taisyklė neteisinga

Sprendimas (Apache .htaccess):

# NETEISINGA: nukreipia viską į pagrindinį puslapį
# RewriteRule ^(.*)$ https://jusudomenas.lt/ [L,R=301]

# TEISINGA: išsaugo URL struktūrą
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Sprendimas (Nginx):

# NETEISINGA:
# return 301 https://jusudomenas.lt/;

# TEISINGA:
return 301 https://$host$request_uri;

7 kategorija: WordPress specifinės SSL problemos

Problema #18: WordPress administravimo pultas nepasiekiamas po SSL

Simptomai: Po SSL diegimo ir URL pakeitimo negalite prisijungti prie wp-admin. Naršyklė rodo peradresavimo kilpą arba klaidą.

Sprendimas (FTP/SSH prieiga):

// wp-config.php - pridėkite šias eilutes
define('WP_HOME', 'https://jusudomenas.lt');
define('WP_SITEURL', 'https://jusudomenas.lt');
define('FORCE_SSL_ADMIN', true);

// Jei naudojate reverse proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Sprendimas (duomenų bazė, jei wp-config nepadeda):

-- phpMyAdmin arba MySQL komandinėje eilutėje
UPDATE wp_options SET option_value = 'https://jusudomenas.lt'
WHERE option_name = 'siteurl';

UPDATE wp_options SET option_value = 'https://jusudomenas.lt'
WHERE option_name = 'home';

Jei vis dar nepavyksta:

# Laikinai išjunkite visus įskiepius
# pervardydami plugins katalogą
mv /var/www/jusudomenas.lt/wp-content/plugins \
   /var/www/jusudomenas.lt/wp-content/plugins.bak

# Prisijunkite prie wp-admin
# Tada grąžinkite plugins katalogą
mv /var/www/jusudomenas.lt/wp-content/plugins.bak \
   /var/www/jusudomenas.lt/wp-content/plugins

# Aktyvuokite įskiepius po vieną, kad rastumėte probleminį

Problema #19: WooCommerce mokėjimo puslapis nerodo spynelės

Simptomai: Visuose puslapiuose spynelė rodoma, bet checkout (mokėjimo) puslapyje, ne.

Priežastys:

  • Mokėjimo vartų widgetas kraunamas per HTTP
  • WooCommerce šablono failuose yra HTTP nuorodų
  • Trečiųjų šalių mokėjimo modulio problema

Diagnostika:

Atidarykite checkout puslapį, spauskite F12 → Console ir ieškokite „Mixed Content” pranešimų. Jie tiksliai nurodys, kuris resursas kelia problemą.

Sprendimas:

# Patikrinkite WooCommerce šablonus
grep -r "http://" /var/www/jusudomenas.lt/wp-content/plugins/woocommerce/

# Patikrinkite mokėjimo modulio nustatymus
# WooCommerce → Settings → Payments → kiekvieno modulio nustatymai
# Atnaujinkite visus URL iš http:// į https://

Problema #20: WordPress REST API ir SSL klaidos

Simptomai: Gutenberg redaktorius neveikia, rodomas „The response is not a valid JSON response” pranešimas. WordPress temos customizer neveikia.

Priežastis: REST API endpoint’ai grąžina HTTP peradresavimą vietoj JSON atsakymo.

Diagnostika:

# Patikrinkite REST API atsakymą
curl -I https://jusudomenas.lt/wp-json/wp/v2/posts

# Jei matote 301 arba 302 peradresavimą vietoj 200 OK,
# REST API peradresuojamas ir JSON atsakymas prarandamas

Sprendimas:

// wp-config.php
define('WP_HOME', 'https://jusudomenas.lt');
define('WP_SITEURL', 'https://jusudomenas.lt');

Taip pat patikrinkite, ar .htaccess neturi taisyklių, kurios peradresuoja REST API URL.

8 kategorija: Cloudflare ir CDN specifinės problemos

Problema #21: Cloudflare 525 klaida (SSL Handshake Failed)

Simptomai: Lankytojas mato Cloudflare klaidos puslapį su kodu 525.

Priežastis: Cloudflare negali užmegzti SSL ryšio su jūsų serveriu (origin serveriu). Tai atsitinka, kai Cloudflare SSL režimas yra „Full” arba „Full (Strict)”, bet jūsų serveris neturi galiojančio SSL sertifikato arba sertifikatas klaidingai sukonfigūruotas.

Diagnostika:

# Patikrinkite savo serverio SSL tiesiai (apeinant Cloudflare)
# Suraskite savo serverio IP adresą ir tikrinkite tiesiogiai
curl -I --resolve jusudomenas.lt:443:JUSU_SERVERIO_IP \
  https://jusudomenas.lt

# Patikrinkite sertifikatą tiesiogiai
openssl s_client -connect JUSU_SERVERIO_IP:443 \
  -servername jusudomenas.lt 2>&1 | head -20

Sprendimas:

  1. Įsitikinkite, kad jūsų serveryje yra galiojantis SSL sertifikatas.
  2. Jei naudojate „Full (Strict)” režimą, sertifikatas turi būti išduotas pripažintos CA (Let’s Encrypt tinka).
  3. Jei neturite sertifikato serveryje, galite naudoti Cloudflare Origin Certificate:
  • Cloudflare → SSL/TLS → Origin Server → Create Certificate
  • Atsisiųskite sertifikatą ir įdiekite serveryje
  • Šis sertifikatas galioja tik su Cloudflare proxy

Problema #22: Cloudflare 526 klaida (Invalid SSL Certificate)

Simptomai: Cloudflare klaidos puslapis su kodu 526.

Priežastis: Cloudflare prijungia prie jūsų serverio, bet sertifikatas yra negaliojantis, pasibaigęs arba domeno vardas nesutampa. Ši klaida atsiranda tik su „Full (Strict)” režimu.

Sprendimas:

# Patikrinkite, ar sertifikatas serveryje galioja
openssl s_client -connect JUSU_SERVERIO_IP:443 \
  -servername jusudomenas.lt 2>/dev/null | \
  openssl x509 -noout -dates -subject

# Jei pasibaigęs, atnaujinkite
sudo certbot renew --force-renewal

# Jei domeno vardas nesutampa, pergeneruokite sertifikatą
sudo certbot --nginx -d jusudomenas.lt -d www.jusudomenas.lt

Alternatyva: laikinai pakeiskite Cloudflare SSL režimą iš „Full (Strict)” į „Full” (nerekomenduojama ilgam, bet padeda diagnozuoti problemą).

Problema #23: CDN failai kraunami per HTTP

Simptomai: Pagrindinė svetainė veikia per HTTPS, bet statiniai failai (CSS, JS, paveikslėliai) iš CDN kraunami per HTTP. Naršyklė blokuoja šiuos resursus kaip mixed content.

Priežastis: CDN konfigūracija nenustatyta HTTPS režimui arba svetainės kode naudojami seni HTTP CDN URL.

Sprendimas:

  1. CDN valdymo pulte aktyvuokite HTTPS (beveik visi CDN tiekėjai tai palaiko nemokamai).
  2. Atnaujinkite CDN URL svetainės kode:
// WordPress wp-config.php arba CDN įskiepio nustatymai
// Buvo:
define('CDN_URL', 'http://cdn.jusudomenas.lt');
// Tapo:
define('CDN_URL', 'https://cdn.jusudomenas.lt');
  1. Jei CDN nenaudoja jūsų domeno, o trečiosios šalies URL (pvz., cdn12345.example-cdn.com), patikrinkite, ar tas URL palaiko HTTPS.

9 kategorija: serverio konfigūracijos problemos

Problema #24: Privatus raktas nesutampa su sertifikatu

Simptomai: Žiniatinklio serveris nepasileidžia arba rodo SSL klaidą žurnaluose (logs). Nginx: „SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch”. Apache: „AH02565: Certificate and private key do not match”.

Priežastis: CSR buvo sugeneruotas su vienu privačiu raktu, tačiau serveryje naudojamas kitas privatus raktas. Tai atsitinka, kai:

  • Buvo sugeneruoti keli CSR ir painiojami raktai
  • Privatus raktas buvo perrašytas arba pakeistas per klaidą
  • Sertifikatas buvo atsisiųstas iš kitos sistemos nei ta, kurioje buvo sugeneruotas CSR

Diagnostika:

# Palyginkite sertifikato ir rakto modulus hash'us
openssl x509 -noout -modulus -in /etc/ssl/certs/sertifikatas.crt | openssl md5
openssl rsa -noout -modulus -in /etc/ssl/private/privatusraktas.key | openssl md5

# Jei turite ir CSR, patikrinkite ir jį
openssl req -noout -modulus -in /etc/ssl/certs/uzklausa.csr | openssl md5

# Visi trys turi rodyti IDENTIŠKĄ MD5 reikšmę
# Pavyzdžiui:
# (stdin)= abc123def456...
# (stdin)= abc123def456...    ← sutampa, gerai
# (stdin)= xyz789ghi012...    ← nesutampa, problema

Sprendimas:

Jei raktai nesutampa, turite pergeneruoti sertifikatą:

# 1. Sugeneruokite naują CSR su nauju privačiu raktu
openssl req -new -newkey rsa:2048 -nodes \
  -keyout naujas_privatusraktas.key \
  -out naujas_csr.csr \
  -subj "/C=LT/ST=Vilnius/L=Vilnius/O=Jusu Imone/CN=jusudomenas.lt"

# 2. Pateikite naują CSR sertifikato tiekėjui (reissue)
# Dauguma mokamų tiekėjų leidžia tai padaryti nemokamai

# 3. Let's Encrypt: tiesiog gaukite naują sertifikatą
sudo certbot certonly --nginx -d jusudomenas.lt -d www.jusudomenas.lt

Prevencija:

  • Saugokite privataus rakto failą vienoje aiškiai pažymėtoje vietoje
  • Niekada negeneruokite kelių CSR to paties domeno ir nepainiokite raktų
  • Sukurkite privataus rakto atsarginę kopiją saugioje vietoje (šifruotoje saugykloje, ne el. pašte)

Problema #25: Nginx arba Apache nepasileidžia po SSL konfigūracijos pakeitimo

Simptomai: Po konfigūracijos pakeitimo žiniatinklio serveris nepasileidžia. systemctl status nginx (ar apache2) rodo „failed” būseną.

Diagnostika:

# Nginx: patikrinkite konfigūraciją prieš paleidimą
sudo nginx -t
# Rodos tikslią klaidos eilutę ir failą

# Apache: patikrinkite konfigūraciją
sudo apachectl configtest

# Peržiūrėkite klaidų žurnalą
sudo tail -20 /var/log/nginx/error.log
sudo tail -20 /var/log/apache2/error.log

# Patikrinkite, ar sertifikato failai egzistuoja ir pasiekiami
sudo ls -la /etc/ssl/certs/fullchain.pem
sudo ls -la /etc/ssl/private/privkey.pem

# Patikrinkite failų teises
# Privatus raktas turėtų būti skaitomas tik root
stat -c "%a %U %G" /etc/ssl/private/privkey.pem
# Tikėtina: 600 root root

Dažniausios priežastys ir sprendimai:

Neteisingas failo kelias:

# Klaida žurnale:
# nginx: [emerg] cannot load certificate "/etc/ssl/sertifikatas.crt":
# BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory)

# Sprendimas: patikrinkite ir ištaisykite kelią konfigūracijoje
sudo find /etc/ssl /etc/letsencrypt -name "*.pem" -o -name "*.crt" 2>/dev/null

Failų teisių problema:

# Klaida: Permission denied
# Sprendimas: nustatykite teisingas teises
sudo chmod 600 /etc/ssl/private/privkey.pem
sudo chmod 644 /etc/ssl/certs/fullchain.pem
sudo chown root:root /etc/ssl/private/privkey.pem

Sertifikato failas tuščias arba sugadintas:

# Patikrinkite failo dydį
ls -la /etc/ssl/certs/fullchain.pem
# Jei 0 baitų, failas tuščias

# Patikrinkite failo turinį
head -1 /etc/ssl/certs/fullchain.pem
# Turi prasidėti: -----BEGIN CERTIFICATE-----

head -1 /etc/ssl/private/privkey.pem
# Turi prasidėti: -----BEGIN PRIVATE KEY-----
# arba: -----BEGIN RSA PRIVATE KEY-----

443 portas jau užimtas kito proceso:

# Patikrinkite, kas naudoja 443 portą
sudo lsof -i :443
sudo netstat -tlnp | grep 443

# Jei kitas procesas naudoja portą, sustabdykite jį
# arba pakeiskite konfigūraciją

Sintaksės klaida konfigūracijoje:

# Nginx dažna klaida: trūksta kabliataškio
# server {
#     listen 443 ssl    ← trūksta ;
#     ...
# }

# Apache dažna klaida: neuždaryta direktyva
# <VirtualHost *:443>
#     ...
# (trūksta </VirtualHost>)

Visada naudokite nginx -t arba apachectl configtest prieš perkraunant serverį. Tai yra geriausias būdas išvengti prastovos dėl konfigūracijos klaidų.

Retesnės, bet svarbios problemos

HSTS problema: negaliu grįžti prie HTTP

Situacija: Aktyvavote HSTS su ilgu max-age, ir dabar net pašalinus SSL, naršyklė automatiškai nukreipia į HTTPS.

Priežastis: HSTS instrukcija yra išsaugota lankytojų naršyklių talpykloje. Kol nepasibaigs max-age terminas, naršyklės priverstinai naudos HTTPS.

Sprendimas (serverio pusėje):

# Nustatykite max-age=0, kad naršyklės pašalintų HSTS
add_header Strict-Transport-Security "max-age=0" always;

Palaikykite šią antraštę bent kelias savaites, kol lankytojų naršyklės atnaujins HSTS įrašą.

Sprendimas (konkretaus lankytojo naršyklėje):

  • Chrome: eikite į chrome://net-internals/#hsts, skiltyje „Delete domain security policies” įveskite domeną ir spauskite „Delete”.
  • Firefox: uždarykite naršyklę, raskite SiteSecurityServiceState.json failą profilyje ir pašalinkite atitinkamą domeno eilutę.

Prevencija: Visada pradėkite HSTS su trumpu max-age (pvz., 300 sekundžių) ir laipsniškai didinkite.

Sertifikatas atšauktas (revoked)

Simptomai: Naršyklė rodo NET::ERR_CERT_REVOKED.

Priežastys:

  • Privatus raktas buvo kompromituotas ir jūs (arba kas nors) paprašė atšaukti sertifikatą
  • Sertifikavimo institucija atšaukė sertifikatą dėl politikos pažeidimo (pvz., klaidingai validuotas domenas)
  • CAA DNS įrašų konfliktas

Diagnostika:

# Patikrinkite sertifikato būseną per OCSP
CERT_URL=$(openssl x509 -in sertifikatas.crt -noout -ocsp_uri)
openssl ocsp -issuer tarpinis.crt -cert sertifikatas.crt \
  -url "$CERT_URL" -resp_text 2>/dev/null | \
  grep "Cert Status"

# Tikėtinas: "Cert Status: good" (viskas gerai)
# Problema: "Cert Status: revoked" (atšauktas)

Sprendimas:

  1. Sugeneruokite naują privatų raktą ir CSR.
  2. Gaukite naują sertifikatą iš sertifikavimo institucijos.
  3. Let’s Encrypt: sudo certbot certonly --force-renewal --nginx -d jusudomenas.lt

Android senų versijų suderinamumas

Simptomai: Svetainė veikia visose naršyklėse, bet senesnių Android versijų (5.x, 6.x) naudotojai mato SSL klaidą.

Priežastis: Let’s Encrypt šakninis sertifikatas ISRG Root X1 nėra įtrauktas į senesnių Android versijų pasitikėjimo saugyklą. Let’s Encrypt naudojo kryžminį pasirašymą su DST Root CA X3, kuris baigėsi 2021 m. rugsėjį.

Diagnostika:

# Patikrinkite sertifikatų grandinę
openssl s_client -connect jusudomenas.lt:443 \
  -servername jusudomenas.lt -showcerts 2>/dev/null | \
  grep -E "s:|i:"

Sprendimas:

Jei turite daug lankytojų su senais Android įrenginiais, apsvarstykite:

  1. Mokamą sertifikatą iš tiekėjo, kurio šakninis sertifikatas yra senesnių Android versijų saugykloje (DigiCert, Sectigo).
  2. Alternatyvią sertifikatų grandinę (kai kurios CA siūlo kelis grandinės variantus).

Praktiškai 2026 metais šis suderinamumas tampa vis mažiau aktualus, nes Android 7.0+ (API 24) jau turi ISRG Root X1, o senesnių versijų dalis sparčiai mažėja.

OCSP Stapling klaidos

Simptomai: SSL Labs rodo „OCSP stapling: No” arba „OCSP ERROR”. Pirmo prisijungimo laikas yra lėtesnis.

Diagnostika:

# Patikrinkite OCSP Stapling
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 -status 2>/dev/null | \
  grep -A5 "OCSP Response"

# Jei nematote OCSP atsako arba matote klaidą,
# OCSP Stapling neveikia arba nesukonfigūruotas

Sprendimas (Nginx):

ssl_stapling on;
ssl_stapling_verify on;

# Svarbu: naudokite fullchain (su tarpiniais sertifikatais)
ssl_trusted_certificate /etc/ssl/certs/fullchain.pem;

# DNS resolver turi būti nurodytas
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Po konfigūracijos pakeitimo:

sudo nginx -t && sudo systemctl reload nginx

# Palaukite 1-2 minutes ir patikrinkite
echo | openssl s_client -servername jusudomenas.lt \
  -connect jusudomenas.lt:443 -status 2>/dev/null | \
  grep "OCSP Response Status"

Jei OCSP Stapling vis dar neveikia:

# Patikrinkite, ar Nginx gali pasiekti OCSP responderio serverį
openssl x509 -in sertifikatas.crt -noout -ocsp_uri
# Parodys OCSP URL

# Patikrinkite, ar serveris gali prisijungti prie to URL
curl -I $(openssl x509 -in sertifikatas.crt -noout -ocsp_uri)

SSL problemų sprendimo darbo eigos schema

Kai susiduriate su SSL klaida, naudokite šią sprendimų eigą:

graph TD
    A["SSL klaida naršyklėje"] --> B{"Koks klaidos kodas?"}
    B --> C["ERR_CERT_DATE_INVALID"]
    B --> D["ERR_CERT_AUTHORITY_INVALID"]
    B --> E["ERR_CERT_COMMON_NAME_INVALID"]
    B --> F["ERR_SSL_PROTOCOL_ERROR"]
    B --> G["ERR_TOO_MANY_REDIRECTS"]
    B --> H["Spynelė nerodoma"]
    C --> C1["Patikrinkite sertifikato datas"]
    C1 --> C2{"Pasibaigęs?"}
    C2 -->|"Taip"| C3["Atnaujinkite sertifikatą"]
    C2 -->|"Ne"| C4["Patikrinkite serverio laikrodį"]
    D --> D1["Patikrinkite sertifikatų grandinę"]
    D1 --> D2{"Grandinė pilna?"}
    D2 -->|"Ne"| D3["Pridėkite CA Bundle"]
    D2 -->|"Taip"| D4["Patikrinkite šakninį sertifikatą"]
    E --> E1["Patikrinkite SAN įrašus"]
    E1 --> E2["Pergeneruokite sertifikatą su teisingais domenais"]
    F --> F1["Patikrinkite 443 portą ir SSL modulį"]
    G --> G1["Patikrinkite peradresavimo grandinę su curl -I -L"]
    H --> H1["Ieškokite mixed content klaidų konsolėje"]

Greitasis diagnostikos skriptas

Šis skriptas atlieka visus pagrindinius SSL patikrinimus vienu paleidimmu:

#!/bin/bash
# ssl-diagnose.sh - pilna SSL diagnostika

DOMAIN=${1:-"jusudomenas.lt"}
PORT=${2:-443}

echo "============================================"
echo "SSL DIAGNOSTIKA: $DOMAIN:$PORT"
echo "============================================"
echo ""

# 1. Ryšio patikrinimas
echo "--- 1. Ryšio patikrinimas ---"
timeout 5 bash -c "echo > /dev/tcp/$DOMAIN/$PORT" 2>/dev/null
if [ $? -eq 0 ]; then
    echo "✓ Serveris pasiekiamas per $PORT portą"
else
    echo "✗ KLAIDA: Serveris nepasiekiamas per $PORT portą"
    echo "  Patikrinkite ugniasienę ir ar serveris veikia"
    exit 1
fi
echo ""

# 2. Sertifikato datos
echo "--- 2. Sertifikato galiojimas ---"
DATES=$(echo | openssl s_client -servername $DOMAIN \
  -connect $DOMAIN:$PORT 2>/dev/null | \
  openssl x509 -noout -dates 2>/dev/null)
if [ -z "$DATES" ]; then
    echo "✗ KLAIDA: Nepavyko gauti sertifikato"
    exit 1
fi
echo "$DATES"
ENDDATE=$(echo "$DATES" | grep notAfter | cut -d= -f2)
DAYS_LEFT=$(( ($(date -d "$ENDDATE" +%s) - $(date +%s)) / 86400 ))
if [ $DAYS_LEFT -le 0 ]; then
    echo "✗ KRITINĖ: Sertifikatas PASIBAIGĘS prieš $((DAYS_LEFT * -1)) dienų!"
elif [ $DAYS_LEFT -le 14 ]; then
    echo "⚠ ĮSPĖJIMAS: Liko tik $DAYS_LEFT dienų!"
elif [ $DAYS_LEFT -le 30 ]; then
    echo "⚠ Dėmesio: Liko $DAYS_LEFT dienų"
else
    echo "✓ Liko $DAYS_LEFT dienų"
fi
echo ""

# 3. Domeno atitikimas
echo "--- 3. Domeno atitikimas ---"
SAN=$(echo | openssl s_client -servername $DOMAIN \
  -connect $DOMAIN:$PORT 2>/dev/null | \
  openssl x509 -noout -ext subjectAltName 2>/dev/null)
echo "$SAN"
if echo "$SAN" | grep -q "$DOMAIN"; then
    echo "✓ Domenas $DOMAIN rastas sertifikate"
else
    echo "✗ KLAIDA: Domenas $DOMAIN NERASTAS sertifikate!"
fi
echo ""

# 4. Sertifikatų grandinė
echo "--- 4. Sertifikatų grandinė ---"
CHAIN=$(openssl s_client -connect $DOMAIN:$PORT \
  -servername $DOMAIN -showcerts 2>/dev/null | \
  grep -c "BEGIN CERTIFICATE")
echo "Sertifikatų skaičius grandinėje: $CHAIN"
if [ "$CHAIN" -lt 2 ]; then
    echo "⚠ ĮSPĖJIMAS: Gali trūkti tarpinių sertifikatų"
else
    echo "✓ Grandinė atrodo pilna"
fi

VERIFY=$(echo | openssl s_client -servername $DOMAIN \
  -connect $DOMAIN:$PORT 2>&1 | grep "Verify return code")
echo "$VERIFY"
if echo "$VERIFY" | grep -q "0 (ok)"; then
    echo "✓ Sertifikato verifikacija sėkminga"
else
    echo "✗ KLAIDA: Sertifikato verifikacija nepavyko"
fi
echo ""

# 5. TLS versija ir šifravimas
echo "--- 5. TLS konfigūracija ---"
PROTO=$(echo | openssl s_client -servername $DOMAIN \
  -connect $DOMAIN:$PORT 2>/dev/null | grep "Protocol")
CIPHER=$(echo | openssl s_client -servername $DOMAIN \
  -connect $DOMAIN:$PORT 2>/dev/null | grep "Cipher")
echo "$PROTO"
echo "$CIPHER"
echo ""

# 6. HSTS antraštė
echo "--- 6. HSTS ---"
HSTS=$(curl -sI https://$DOMAIN 2>/dev/null | \
  grep -i "strict-transport-security")
if [ -n "$HSTS" ]; then
    echo "✓ $HSTS"
else
    echo "⚠ HSTS antraštė nerasta"
fi
echo ""

# 7. HTTP → HTTPS peradresavimas
echo "--- 7. HTTP peradresavimas ---"
REDIRECT=$(curl -sI http://$DOMAIN 2>/dev/null | head -5)
echo "$REDIRECT"
if echo "$REDIRECT" | grep -q "301"; then
    echo "✓ 301 peradresavimas nustatytas"
elif echo "$REDIRECT" | grep -q "302"; then
    echo "⚠ 302 peradresavimas (turėtų būti 301)"
else
    echo "✗ HTTP peradresavimas nerastas"
fi
echo ""

echo "============================================"
echo "DIAGNOSTIKA BAIGTA"
echo "============================================"

Naudojimas:

chmod +x ssl-diagnose.sh
./ssl-diagnose.sh jusudomenas.lt
./ssl-diagnose.sh kitasdomenas.com 8443  # alternatyvus portas

Prevencinės priemonės: kaip išvengti SSL problemų

1. Automatizuokite viską, ką galite

# Certbot automatinis atnaujinimas
sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer

# Patikrinkite, ar timer veikia
sudo systemctl list-timers | grep certbot

2. Stebėkite sertifikatus proaktyviai

Nustatykite bent vieną stebėjimo sistemą:

  • UptimeRobot (nemokamas, paprastas)
  • Prometheus + Blackbox Exporter (pažangus, centralizuotas)
  • Cron skriptas su el. pašto pranešimais (minimalus)

3. Testuokite prieš diegimą

# Visada tikrinkite konfigūraciją prieš perkraunant serverį
sudo nginx -t
sudo apachectl configtest

# Testuokite Certbot atnaujinimą be tikro atnaujinimo
sudo certbot renew --dry-run

4. Turėkite atstatymo planą

  • Saugokite ankstesnio sertifikato ir privataus rakto kopijas
  • Turėkite serverio konfigūracijos atsarginę kopiją
  • Žinokite, kaip greitai grįžti prie ankstesnės konfigūracijos
# Prieš kiekvieną SSL pakeitimą
sudo cp /etc/nginx/sites-available/jusudomenas.lt \
  /etc/nginx/sites-available/jusudomenas.lt.bak.$(date +%Y%m%d)

5. Dokumentuokite savo SSL infrastruktūrą

Sukurkite dokumentą, kuriame nurodyta:

  • Kiekvieno domeno sertifikato tipas (Let’s Encrypt, DigiCert ir t.t.)
  • Sertifikato galiojimo data
  • Kur saugomi sertifikato failai
  • Kas atsakingas už atnaujinimą
  • Kaip atlikti atnaujinimą rankiniu būdu (jei automatinis nepavyktų)

6. Naudokite DNS CAA įrašus

jusudomenas.lt.  IN  CAA  0 issue "letsencrypt.org"
jusudomenas.lt.  IN  CAA  0 iodef "mailto:admin@jusudomenas.lt"

CAA įrašai užkerta kelią neteisėtam sertifikatų išdavimui jūsų domeno vardu.

7. Reguliariai atlikite SSL auditą

Kartą per ketvirtį:

  • Paleiskite SSL Labs testą visiems domenams
  • Patikrinkite, ar nėra senų TLS protokolų
  • Patikrinkite šifravimo algoritmų stiprumą
  • Peržiūrėkite Certificate Transparency žurnalus

Dažnai užduodami klausimai

Kodėl SSL sertifikatas veikia viename įrenginyje, bet ne kitame?
Tai paprastai rodo sertifikatų grandinės problemą. Šiuolaikinės darbalaukio naršyklės (Chrome, Firefox) gali automatiškai atsisiųsti trūkstamus tarpinius sertifikatus, todėl viskas atrodo gerai. Tačiau mobiliosios aplikacijos, senesni įrenginiai, API klientai ir programavimo kalbų HTTP bibliotekos to nedaro. Sprendimas: visada įdiekite pilną sertifikatų grandinę serveryje.

Ar galiu ignoruoti SSL klaidą ir vis tiek pasiekti svetainę?
Techniškai galite spausti „Advanced → Proceed” daugelyje naršyklių. Tačiau tai yra pavojinga: jūs nežinote, ar svetainė yra tikra, ar tai phishing puslapis. Niekada neįvedinėkite slaptažodžių ar asmeninių duomenų svetainėje, kuri rodo SSL klaidą. Kaip svetainės savininkas, niekada neprašykite lankytojų ignoruoti SSL klaidą, tai yra nesaugi praktika.

Kodėl mano SSL Labs vertinimas B, o ne A+?
B vertinimas dažniausiai reiškia, kad palaikote senesnius TLS protokolus (TLS 1.0 ar TLS 1.1). Pasirinkite tik TLS 1.2 ir TLS 1.3, pašalinkite silpnus šifravimo algoritmus ir aktyvuokite HSTS. Po šių pakeitimų turėtumėte gauti A arba A+.

Ką daryti, jei SSL klaida atsiranda tik tam tikru paros metu?
Tai gali rodyti serverio apkrovos problemą. Kai serveris perkrautas, TLS handshake gali nepavykti dėl atminties trūkumo ar proceso limito. Patikrinkite serverio resursus (CPU, RAM) piko metu. Padidinkite SSL sesijos talpyklą ir aktyvuokite OCSP Stapling, kad sumažintumėte SSL apkrovą.

Kaip ištaisyti SSL klaidą el. pašto serveryje (SMTP)?
El. pašto SSL problemos sprendžiamos panašiai kaip žiniatinklio: patikrinkite sertifikato galiojimą, grandinę ir domeno atitikimą. Skirtumas: el. pašto serveriai naudoja 465 (SMTPS), 587 (STARTTLS), 993 (IMAPS) ir 995 (POP3S) portus.

# SMTP patikrinimas
openssl s_client -connect mail.jusudomenas.lt:465
# arba STARTTLS
openssl s_client -connect mail.jusudomenas.lt:587 -starttls smtp
# IMAP
openssl s_client -connect mail.jusudomenas.lt:993

Ar galiu naudoti tą patį SSL sertifikatą ir žiniatinklio serveriui, ir el. pašto serveriui?
Taip, jei sertifikatas apima el. pašto serverio domeno vardą. Pavyzdžiui, jei jūsų el. pašto serveris yra mail.jusudomenas.lt, sertifikatas turi apimti šį subdomeną (arba naudokite Wildcard *.jusudomenas.lt). Privataus rakto ir sertifikato failai gali būti tie patys abiejuose serveriuose.

Apibendrinimas

SSL problemos, nors ir atrodančios baugiai, turi aiškias priežastis ir konkrečius sprendimus. 95 % visų SSL klaidų patenka į vieną iš šių kategorijų:

  1. Pasibaigęs sertifikatas → atnaujinkite ir nustatykite automatinį atnaujinimą
  2. Trūkstama sertifikatų grandinė → pridėkite CA Bundle failą
  3. Domeno vardo neatitikimas → pergeneruokite sertifikatą su teisingais domenais
  4. Peradresavimo kilpa → patikrinkite Cloudflare režimą ir pašalinkite dvigubus peradresavimus
  5. Mixed content → pakeiskite HTTP nuorodas į HTTPS turinyje ir resursuose

Kiekvienai problemai taikykite tą pačią diagnostikos eigą: surinkite informaciją (OpenSSL komandos, naršyklės konsolė), identifikuokite priežastį, pritaikykite sprendimą ir patikrinkite rezultatą (SSL Labs testas, naršyklės patikrinimas).

Geriausias SSL problemų sprendimas yra prevencija: automatinis sertifikatų atnaujinimas, proaktyvus stebėjimas su pranešimais ir reguliarūs saugumo auditai. Investuokite valandą prevencijai šiandien, ir sutaupysite dienas skubotų taisymų ateityje.

Į viršų