Како OpenVPN решава сертификат и кључ: уграђени PEM или путања

Порука каже да OpenVPN не може да учита уграђени сертификат, а назив датотеке који носите у глави тврди супротно. Оно што је парсер примио важније је од онога што садржи датотечни систем, јер директива cert прихвата две потпуно различите врсте вредности. Једна је путања коју отвара; друга је PEM текст који је стигао унутар конфигурације. Док не знате који је облик добио клијент који ради, свака поправка је нагађање.

Два облика чувања, једна директива

Директиве cert, key и ca прихватају путању или уграђени блок. Када је вредност путања, OpenVPN отвара ту датотеку и чита објекат са диска. Када конфигурација садржи блок ограничен cert ознакама, иста директива уместо тога троши садржај између тих ознака, и посебна датотека није укључена.

Оба облика на крају дају исту врсту објекта, зато радно распоређивање може да прелази између њих без икакве друге промене. Профил који носи уграђени клијентски сертификат и приватни кључ је самодовољан, а његово копирање на другу машину ради и без копирања директоријума са сертификатима.

Обрнуто није тачно. Стављање client.crt поред профила који уграђује сопствене податке не мења ништа, јер се ништа у конфигурацији не позива на ту датотеку. То је најчешћи разлог зашто датотека која очигледно постоји изгледа занемарена.

Како уграђени блок постаје објекат

Уграђени садржај се извлачи из конфигурације и предаје PEM парсеру као текст. Тај парсер очекује уобичајене границе: ред BEGIN, base64 садржај и одговарајући ред END. Ако је блок одсечен неуспешним копирањем, умотан у HTML од стране странице за преузимање или отворен у уређивачу који је нормализовао цртице, парсер пада на садржају који изгледа присутно.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

Зато је и формулација грешке обмањујућа. Реч уграђени описује где је учитавач погледао, а не шта је тамо нашао. Датотека наведена у конфигурацији и објекат уграђен у њу могу да произведу исту жалбу када су основни бајтови неупотребљиви.

Проверите који облик учитани профил заиста користи, а не коју је датотеку ваш уређивач случајно отворио:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

Како се решава референца на путању

Вредност путање отвара се релативно према радном директоријуму клијента, не према директоријуму који садржи конфигурацију. Под systemd тим радним директоријумом је оно што јединица постави, а интерактивно покретање из ваше љуске наслеђује нешто сасвим друго. Зато иста конфигурациона датотека може да ради када је тестирате ручно, а да падне као сервис.

Релативне путање наслеђују исту двосмисленост. Када видите голи назив датотеке, питајте који је тренутни директоријум процеса у продукцији, уместо да претпоставите да се поклапа са вашим терминалом.

За сертификат који се чува одвојено, офлајн анализа потврђује објекат пре него што почнете да отклањате грешке у било чему изнад њега:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

Те команде доказују да су датотеке читљиве и структурно важеће. Оне не доказују да партнер верује издаваоцу, да је сертификат још у року важности или да му кључ припада.

Шта грешка парсера може и шта не може да вам каже

Неуспех парсирања лоцира проблем на један улаз и једну фазу. Не говори вам који је од два облика чувања клијент користио и не говори да ли би објекат био прихваћен. То су одвојена питања са одвојеним доказима.

Када парсирање успе, следећи неуспех припада каснијој фази. Одбијање поверења, неподударност намене или неподударност кључа пријављује партнер или TLS слој, а не учитавач. Поновно замењивање исте датотеке неће померити ту грешку.

Држите осетљиву половину изван јавних извештаја док истражујете. Поделите називе директива, текст грешке и структуру блока, уз уклоњен кључни материјал и сваки идентификујући садржај. Приручник openvpn(8) документује оба облика датотечних директива и понашање радног директоријума иза њих.