Грешка в уеб сертификата на Access Server: поправка на празен CA пакет

Празна стойност ca_bundle или повреден PEM спира Admin интерфейса. Проверете сертификата, ключа и веригата като един комплект преди рестарт и не пипайте VPN PKI.

Уеб страница за вход, която не се зарежда, докато DNS се разрешава правилно, обикновено не е DNS проблем. Ако журналът на услугата споменава празен път до пакета сертификати или неуспех при разчитане на PEM за уеб сертификата и частния ключ, HTTPS слушателят няма използваем материал и никакво разрешаване на имена няма да помогне. Поправката е в три ключа на конфигурацията и не изисква преиздаване на нито един клиентски сертификат за VPN.

Към какво всъщност сочат трите ключа

Персонализираният набор уеб сертификати се описва от cs.cert, cs.priv_key и cs.ca_bundle. Всеки пази път до файл и трите се използват заедно от уеб услугата. Сертификат с грешен ключ или файл с верига, който всъщност е крайният сертификат, се проваля като празна стойност: слушателят не може да построи верига, която браузърът да приеме.

Тези ключове принадлежат на Admin и Client уеб интерфейса. Те са отделни от PKI, която издава сертификати на VPN клиенти, затова подмяната не изисква докосване на клиентските профили, сървърния ключ или сертификатния орган. Да приемете уеб TLS повреда като причина за преизграждане на цялата PKI е най-скъпата грешка тук.

Едно разграничение пести време: изрично празна персонализирана стойност не е същото състояние като липса на замяна. Първото дава на анализатора празен път, това казва редът в журнала. Второто оставя Access Server на собствения му материал, затова някои хостове стартират добре след надграждане, а други не.

Защо съществуващ файл все още не се разчита

Анализаторът чете маркираните блокове във файла, не името на файла. .crt, който съдържа частен ключ, верига, записана като едно слято петно там, където се очаква един сертификат, или файл с отрязан последен ред — всички се отхвърлят. RFC 7468 дефинира тези четими етикети, защото те са единственото, което казва на читателя какъв обект следва.

Разгледайте обектите, не разширенията. На Linux хост openssl x509 -noout -subject -issuer -in server.pem и openssl pkey -noout -check -in key.pem отговарят на двата важни въпроса, а сравняването на модула или публичния ключ на двамата доказва, че си принадлежат. Дръжте изхода с частния ключ далеч от тикети и чат журнали; проверката иска отпечатък, не ключа.

Празният път заслужава същото подозрение като повреден файл, защото и двете дават неясни последващи грешки. Ако журналът казва, че пътят до пакета е празен, прочетете запазената стойност, преди да отстранявате грешки във файла.

Върнете се към резерва умишлено

CLI на Access Server има проверка, която приема трите пътя като аргументи и съобщава дали наборът е използваем. Пътищата по-долу са примерни; заменете ги със защитените места на хоста:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Прочетете резултата, преди да докоснете работещата услуга, и само след това импортирайте стойностите и ги приложете чрез документираната операция за инсталираната версия. официалният урок за CLI покрива проверката, импорта в конфигурационната база и стъпката на прилагане, а версията му е по-важна от всяко негово резюме.

Проверете името, което потребителите наистина въвеждат

Когато персонализираният материал е повреден, а валиден вграден резерв още съществува, документираното възстановяване е да премахнете трите персонализирани замени и да оставите Access Server да използва резерва. Първо осигурете конзолен достъп и резервно копие на текущата конфигурация, защото услугата, която ще рестартирате, обслужва административния интерфейс.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Изчистването на цялата конфигурационна база не е ремонт на сертификат. Насочете се към тези три ключа, приложете и потвърдете, че уеб интерфейсът отговаря. Самоподписаните файлове под директорията web-ssl са резервният ресурс, а не работно място: презаписването или прегенерирането им може да премахне единствения работещ материал.

Очаквайте браузърът да покаже различен сертификат, след като резервът влезе в сила. Това е правилният резултат и отговорът е да го проверите чрез доверения си административен процес, а не да учите потребителите да прескачат всяко предупреждение.

Възстановяването приключва само след успешен вход

Възстановяването не е завършено, когато се появи TCP слушател. Проверете DNS името, идентичността на сертификата и веригата за това име, после заредете и двата уеб интерфейса Admin и Client и завършете вход. Проверка на порт не доказва нищо от това.

Access Server 3.1 и по-нови могат да обслужват различни уеб сертификати за всяко SNI име на хост. Ако това е настроено, стандартните ключове и записите за конкретно име са отделни набори и тестването по IP адрес лесно показва различен сертификат от този, който получават потребителите. Поправете и проверете набора за неуспешното име, после повторете теста за вход, преди да затворите инцидента.

Подобни статии