Каде во датотеката со клуч за VPN живеат n, e, d, p и q од RSA
n, e, d, p и q стојат во една структура, а не во имиња на датотеки. Прочитајте RSA клуч за VPN со OpenSSL и поврзете го со неговиот сертификат без да печатите тајни.
Буквите во објаснувањето на RSA именуваат полиња во еден објект, а не датотеки што ги издава алатка за PKI. Датотеката со приватен клуч држи структура чии први полиња се јавни, а чии подоцнежни полиња никогаш не смеат да ја напуштат машината што го завршува тунелот. Меѓу тие два факти лежи најголемиот дел од практичните прашања која датотека одговара на кое прашање. Овој прирачник прво ја чита структурата, а потоа наредбите што ја прегледуваат без да ја истурат.
Потврдете дека клучот е RSA пред да барате прости броеви
Сертификатот докажува дека некој клуч постои и е потпишан; не докажува дека клучот е RSA. Системите можат да се градат на елиптични криви или Ed25519, и истиот распоред на папки служи за сите. Проверете го алгоритмот пред да почнете да барате прости фактори што никогаш не биле таму.
Овие три наредби само за читање одговараат на прашањето и ја запишуваат верзијата на алатката.
openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text
Верзијата е важна зашто имињата на опциите се преместиле меѓу главните изданија. Во излезот на сертификатот пронајдете ја линијата на алгоритмот за јавен клуч и големината на клучот; во излезот на клучот RSA клуч печати модул и јавен експонент. Клучот на елиптична крива наместо тоа печати именувана крива, и никакво пребарување нема да даде n или q од него.
Читајте ја структурата наместо base64
PEM е base64 завиткан во линии на заглавие, и неговото декодирање дава DER, односно серијализирана структура, а не еден огромен цел број. RSA приватните клучеви патуваат во два вообичаени контејнери, PKCS#1 и PKCS#8, и двата се сведуваат на истото множество броеви.
Во случајот со два прости броја приватната структура носи девет полиња: верзија, модул n, јавен експонент e, приватен експонент d, простите броеви p и q, два CRT експоненти и CRT коефициент. RFC 8017 дел A.1 ги дефинира тие компоненти и распоредот ASN.1, и дозволува и повеќе од два прости броја, затоа општ парсер може да испечати дополнителни записи за прости броеви. Обрнете внимание на редоследот, зашто објаснува честа грешка: јавната половина се чува во приватната датотека, па присуството на јавно поле не ја прави таа датотека безбедна за споделување. Сето по него е материјалот што мора да остане на домаќинот.
Кодирањето додава слој што лесно се меша со содржината. openssl asn1parse ја црта структурата како дрво за да стане видлив редот на полињата, и не дешифрира ништо ниту кажува дали клучот е употреблив.
Поврзете сертификат со клуч без да го печатите клучот
Следното прашање обично е дали сертификатот и клучот припаѓаат заедно. Споредувањето на модулите одговара на тоа, но исто така копира материјал близок до приватниот во терминалски запис што може да заврши во тикет. Споредувањето на јавните половини одговара на истото прашање без ништо чувствително на екранот.
openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH
Идентични датотеки значат дека сертификатот ја носи јавната половина од тој клуч, а разлика значи дека држите погрешен пар. Токму тоа несовпаѓање е најчестата причина за тунел што весело преговара и потоа одбива автентикација. Потоа избришете ги двете привремени датотеки; во нив нема ништо тајно, но чиста работна папка полесно се размислува среде инцидент.
Знајте што не се соседните датотеки
Сертификатот не е шифриран јавен клуч што партнерот го отклучува со сертификатот на CA; тој е потпишана врска меѓу јавен клуч и податоци за идентитет. Приватниот клуч за потпис на CA останува одделен од сопствениот сертификат и од секој клиентски клуч. Ни барањето не е сертификат: тоа ги носи бараните информации и јавниот клуч со потпис над барањето, што го прави влез за запишување, а не доказ за право.
| File | Answers | Does not prove |
|---|---|---|
| vpn-client.key | Possession of the private key | That the identity is enrolled |
| vpn-client.crt | A signed binding of public key to identity | That the client holds the matching key |
| vpn-client.csr | The requested binding and public key | That access was granted |
| dh2048.pem | Group parameters for key exchange | Any RSA component |
| crl.pem | Revocation status for certificates | Anything about a private key |
Два од тие записи се мешаат со RSA параметрите доволно често за да бидат именувани двапати. Датотеката со параметри на Diffie-Hellman содржи групни параметри за воспоставување клуч и ниту еден RSA прост број, иако и таа се печати како голем прост број. Списокот за отповикување го објавува статусот на сертификатите и не е место каде приватен експонент би можел да се скрие.
Затоа секоја линија од пописот треба да запише четири работи: тип на објект, сопственик, цел и дали е вклучен приватен материјал. Последната колона одлучува каде датотеката смее да се копира, и токму неа луѓето ја прескокнуваат.
Запишете го спарувањето, потоа проверете го ракувањето
Пред да промените нешто, зачувајте го излезот од проверката со датумот и верзијата на OpenSSL. Тогаш подоцнежната ротација може да се спореди со докази, а не со сеќавање.
openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates
По споредувањето на јавниот клуч, изведете ја патеката што го троши парот: кренете го тунелот, потврдете дека сертификатот се прикажува и прифаќа, и проверете кој идентитет го запишал порталот. Ако клучот и сертификатот се совпаѓаат, а автентикацијата сепак не успева, дефектот е во довербата, мапирањето на идентитетот или политиката за пристап, а не во парот.
За враќање, чувајте го претходниот клуч и сертификат во папка со датум и вратете ги двата заедно, никогаш само еден од двата. Клуч без сертификат и сертификат без клуч не успеваат однакво однадвор, што половично вратените парови ги прави скапи за размрсулање во два часот по полноќ.