Ярослав

Важные данные обычно никогда не хранятся на клиенте, они передаются, используются и удаляются.

Есть ли какие-то ситуации, когда использование httpOnly сессионной куки нас защищает, а вот использование localStorage и sessionStorage уязвимо?

Если есть компроментация клиента, то никак не защищает. Единственное место, это где JS вообще в принципе не используется, т.е. клиенты с отключенным JS. Ну это как в рыцарских доспехах ходить по улице. Неудобно, но вроде как защищает от меча. Только с мечом уже давно не ходят, все больше с автоматами.

Теперь про токены. Токены в теории лучше всего держать не в localStorage, а в sessionStorage. Это хранилище переживает перезагрузки страниц и не расшарено между табами. Т.е. при открытии того же самого адреса в новом табе будет созданая новая сессия. Хранилище очищается при закрытии браузера и таба. Но это жутко неудобно, каждый раз логиниться. Поэтому здравая логика говорит об использовании localStorage, хотя если вы совсем отбитый, то можете хранить токен в сессионой куке.

Если вы прочли те статьи внимательно, то можно понять, что преимущества сессионных кук нивелируются неудобством их использования.
JWT Токены предназначены для микросервисной архитектуры. Т.е. у вас есть некоторый центр аутентификации, который выдает вам токен. Токен этот подписан относительно стойкой криптографией и постоянно ротируется.
Этот токен передается другим микросервисам, которые могут его верифицировать через публичные ключи (JWKS).
Т.е. если вы хотите, вы можете строить свои сервисы так, что они доверяют не только вашему центру аутентификации, но и гуглу с амазоном через OpenID. Есть ситуации, например когда вы хотите разрешить доступ к сервису сотрудникам другой компании. Например, когда такая компания огромна (десятки тысяч сотрудников). Они аутенфицируются у себя, а вы проверяете, что токен выпущен сервисом данной компании. Это не так сложно реализовать.
Реализация авторизации лежит на плечах каждого микросервиса и напрямую завязана на бизнес-логику. Как правило это некий внутренний микросервис, который интегрирован c middleware микросервиса.

В Nginx можно сделать default сервер (который catch-all), а начиная с версии 1.15.9 можно указывать переменные ($ssl_server_name) в пути к файлу сертификата.

Судя по строке
drwxr-xr-x 1 xenon xenon 2813952 Feb 11 20:49 .
в этом каталоге в какой-то момент было очень много (тысячи) файлов.

В ext2/3/4 каталог это такой «специальный файл» в котором записаны имена (и ещё что-то) содержащихся в нём файлов. И если их много, то и сам каталог будет большим. Но при этом механизма уменьшения размера каталога не предусмотрено.
Стандартный вариант, скопировать все файлы из него в новый каталог, удалить этот и переместить новый на его место.

Похоже, ещё пока ничего вы не купили. Для начала - и ключ, и запрос на подпись вы генерируете сами, на доверенном устройстве. Затем CSR отправляете продавцу воздуха в удостоверующий центр, который из него делает валидный сертификат.

Тут должна быть шутка про Firecracker на котором работает AWS Lambda

curl 'http://dhl.com/' \
  -H 'Connection: keep-alive' \
  -H 'Upgrade-Insecure-Requests: 1' \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36' \
  -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
  -H 'Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7' \
  --compressed \
  --insecure -I

TP/1.0 301 Moved Permanently
Location: http://www.dhl.com/
Server: BigIP
Connection: Keep-Alive
Content-Length: 0

Ну, Ярославище, американские законы далеко не всегда можно найти в открытом доступе - хайли лайкли знаете... А вот CRL - можно проверить, у нас не так уж и много крупных CA - thawte, comodo, globalsign... Вряд ли там был сертификат от LE :)

UPD: Нифига не получится. В CRL есть только серийник и код отзыва :) Чел, у которого сертификат, конечно сможет проверить - а другие скорее всего нет :)

UPD2 (большое):
Ну, меня вопрос заинтересовал, и вот какие у меня соображения.

Статья, разумеется, фуфел. У сайта fsb.ru, как и у kremlin.ru никогда не было сертификатов, проверить это можно у всезнающего гугла - сервис проверки. Сервис не находит ничего - то есть ничего не было. То есть, я так полагаю, все эти "35 отозванных сертификатов" на самом деле никогда не существовали, а упомянутые сайты никогда не имели сертификатов.
То есть, получается, что американец пиZDит... как и полагается сейчас настоящему американцу :) Но тем не менее, он как ни странно - прав!

Потому что проблема реально существует. Берем, например, яндекс.

Сертификат выдан внутренним CA Yandex:

CN = Yandex CA
OU = Yandex Certification Authority
O = Yandex LLC
C = RU

...которое ессно не корневой СA, а его сертификат выдан:

CN = Certum Trusted Network CA
OU = Certum Certification Authority
O = Unizeto Technologies S.A.
C = PL

... которое - внезапно - находится (тут музыка, туш, чернила и клей) - в Польше!

Issuer:
    CN=Certum CA,O=U­nizeto Sp. z o.o­.,C=PL
    CN=Certum Truste­d Network CA,OU=­Certum Certifica­tion Authority,O­=Unizeto Technol­ogies S.A.,C=PL
Serial:
    1961572933532405­2664386507102252­1293608
    279744
    4772842536756395­3368335862826026­879003
    9458922105397704­9342468936609165­78283
Not valid before:
    2008-10-22 12:07­:37 UTC
Not valid after:
    2027-06-10 10:46­:39 UTC
    2029-12-31 12:07­:37 UTC
    2025-12-30 23:59­:59 UTC
Key size:
    2048
Signature Algorithm:
    sha256WithRSAEnc­ryption
    sha1WithRSAEncry­ption

basicConstraints:
    CA:TRUE
subjectKeyIdentifier:
    08:76:CD:CB:07:F­F:24:F6:C5:CD:ED­:BB:90:BC:E2:84:­37:46:75:F7
authorityKeyIdentifier:
    DirName:/C=PL/O=­Unizeto Sp. z o.­o./CN=Certum CA­serial:01:00:20
keyUsage:
    Certificate Sign­, CRL Sign
crlDistributionPoints:
    Full Name:­ URI:http://crl­.certum.pl/ca.cr­l
authorityInfoAccess:
    OCSP - URI:http:­//subca.ocsp-cer­tum.com­CA Issuers - URI­:http://reposito­ry.certum.pl/ca.­cer
certificatePolicies:
    Policy: X509v3 A­ny Policy­ CPS: http://ww­w.certum.pl/CPS
    Policy: X509v3 A­ny Policy­ CPS: https://w­ww.certum.pl/CPS

(пруф - вот)

То есть, одним движением мышки Certum отзывает сертификат субцентра яндекса - и все сертификаты, выпущенные им, превращаются... в тыкву!

Есть от чего с ума сойти...

Ну и еще момент. Имея сертификат сайта - можно достаточно просто проверить факт его отозванности. Вот статья на хабре, она короткая, но полезные команды там есть.