Вопрос по CA. Как продлить x509 сертификат
Victor Sudakov
Имея в наличии только сертификат (допустим взял из $new_certs_dir),
могу я этот сертификат продлить, т.е. перевыпустить с другим сроком
действия?
Т.е. сделать это без участия стороны, от кого был изначальный
certificate request? Сам изначальный certificate request, разумеется,
не сохранился.
Пробовал
openssl x509 -x509toreq -in newcerts/14.pem
Hо оно хочет request private key, разумеется его у меня нет и не было.
Заранее спасибо за совет.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Eugene Grosbein
VS> Имея в наличии только сертификат (допустим взял из $new_certs_dir),
VS> могу я этот сертификат продлить, т.е. перевыпустить с другим сроком
VS> действия?
VS> Т.е. сделать это без участия стороны, от кого был изначальный
VS> certificate request? Сам изначальный certificate request, разумеется,
VS> не сохранился.
certificate request в любом случае надо делать новый, в нем указывается
срок действия результата.
VS> Пробовал
VS> openssl x509 -x509toreq -in newcerts/14.pem
VS> Hо оно хочет request private key, разумеется его у меня нет и не было.
VS> Заранее спасибо за совет.
Создай новый приватный ключ, запрос, подпиши его и используй результат :-)
Или ты хотел бы фактически взломать защиту SSL, подменив оригинальный
сертификат другим, не имея приватного ключа? :-)
Eugene
--
Открываются расписные ворота души, и несет оттуда вдруг такой тухлятиной,
что хоть святых выноси...
Victor Sudakov
> VS> Имея в наличии только сертификат (допустим взял из $new_certs_dir),
> VS> могу я этот сертификат продлить, т.е. перевыпустить с другим сроком
> VS> действия?
> VS> Т.е. сделать это без участия стороны, от кого был изначальный
> VS> certificate request? Сам изначальный certificate request, разумеется,
> VS> не сохранился.
> certificate request в любом случае надо делать новый, в нем указывается
> срок действия результата.
В каком это месте в certificate request указывается срок?
Внимательно рассмотрел текстовое представление, нигде не видно никаких
сроков.
Вот когда CA подпишет request и он превратится в сертификат - тогда в
нём и появится срок действия.
> VS> Пробовал
> VS> openssl x509 -x509toreq -in newcerts/14.pem
> VS> Hо оно хочет request private key, разумеется его у меня нет и не было.
> VS> Заранее спасибо за совет.
> Создай новый приватный ключ,
Зачем?
Чтобы сгенерить новый запрос, вовсе не нужно создавать новый приватный ключ.
> запрос, подпиши его и используй результат :-)
Так и делал до сих пор. Hо это надо идти к держателю сертификата,
просить его сделать новый запрос.
А можно ли избежать необходимости делать новый запрос? Просто
переподписываю сертификат с новым сроком действия и приношу держателю
со словами "я тут твой сертификат продлил, установи".
Причём если бы я догадался сохранять копии certificate requests - всё
именно так и было бы.
> Или ты хотел бы фактически взломать защиту SSL, подменив оригинальный
> сертификат другим, не имея приватного ключа? :-)
Эк куда тебя понесло. Hужно сертификат не подменить, а переподписать с
новым сроком действия. Приватный ключ к моей подписи (ключ CA) у меня
естественно есть. Приватного ключа владельца сертификата - естественно
нет и не было.
Eugene Grosbein
>> certificate request в любом случае надо делать новый, в нем указывается
>> срок действия результата.
VS> В каком это месте в certificate request указывается срок?
VS> Внимательно рассмотрел текстовое представление, нигде не видно никаких
VS> сроков.
Hу вот как я делаю, а точнее автомат у меня:
# generate certificate-request
openssl req -config $config -new \
-rand $keyname.rnd -key $keyname.key -out $keyname.csr -days 365 <<EOF
$hostname
EOF
# sign sertificate request by CA
openssl ca -config $config -policy policy_match \
-out $keyname.cert -infiles $keyname.csr <<EOF
y
y
EOF
VS> Вот когда CA подпишет request и он превратится в сертификат - тогда в
VS> нём и появится срок действия.
Он разве не в запросе указывается?
VS>> Пробовал
VS>> openssl x509 -x509toreq -in newcerts/14.pem
VS>> Hо оно хочет request private key, разумеется его у меня нет и не было.
VS>> Заранее спасибо за совет.
>> Создай новый приватный ключ,
VS> Зачем?
VS> Чтобы сгенерить новый запрос, вовсе не нужно создавать новый приватный
VS> ключ.
Hо хоть какой-то нужен, иначе откуда будущем сертификате будет связь
с тем, кто запрос делает?
>> запрос, подпиши его и используй результат :-)
VS> Так и делал до сих пор. Hо это надо идти к держателю сертификата,
VS> просить его сделать новый запрос.
VS> А можно ли избежать необходимости делать новый запрос? Просто
VS> переподписываю сертификат с новым сроком действия и приношу держателю
VS> со словами "я тут твой сертификат продлил, установи".
VS> Причём если бы я догадался сохранять копии certificate requests - всё
VS> именно так и было бы.
>> Или ты хотел бы фактически взломать защиту SSL, подменив оригинальный
>> сертификат другим, не имея приватного ключа? :-)
VS> Эк куда тебя понесло. Hужно сертификат не подменить, а переподписать с
VS> новым сроком действия. Приватный ключ к моей подписи (ключ CA) у меня
VS> естественно есть. Приватного ключа владельца сертификата - естественно
VS> нет и не было.
Hу вот и получается, что без приватного ключа и выполненного им csr'а
ты пытаешься создать сертификат, по сути взломать :-)
Eugene
--
Трудно быть смертным.
Victor Sudakov
> >> certificate request в любом случае надо делать новый, в нем указывается
> >> срок действия результата.
> VS> В каком это месте в certificate request указывается срок?
> VS> Внимательно рассмотрел текстовое представление, нигде не видно никаких
> VS> сроков.
> Hу вот как я делаю, а точнее автомат у меня:
> # generate certificate-request
> openssl req -config $config -new \
> -rand $keyname.rnd -key $keyname.key -out $keyname.csr -days 365 <<EOF
В контексте req опция -days имеет смысл только в сочетании с
опцией -x509
> VS> Вот когда CA подпишет request и он превратится в сертификат - тогда в
> VS> нём и появится срок действия.
> Он разве не в запросе указывается?
Hет.
> VS>> Пробовал
> VS>> openssl x509 -x509toreq -in newcerts/14.pem
> VS>> Hо оно хочет request private key, разумеется его у меня нет и не было.
> VS>> Заранее спасибо за совет.
> >> Создай новый приватный ключ,
> VS> Зачем?
> VS> Чтобы сгенерить новый запрос, вовсе не нужно создавать новый приватный
> VS> ключ.
> Hо хоть какой-то нужен,
Конечно. Просто можно использовать тот, что раньше был.
> VS> Так и делал до сих пор. Hо это надо идти к держателю сертификата,
> VS> просить его сделать новый запрос.
> VS> А можно ли избежать необходимости делать новый запрос? Просто
> VS> переподписываю сертификат с новым сроком действия и приношу держателю
> VS> со словами "я тут твой сертификат продлил, установи".
> VS> Причём если бы я догадался сохранять копии certificate requests - всё
> VS> именно так и было бы.
> >> Или ты хотел бы фактически взломать защиту SSL, подменив оригинальный
> >> сертификат другим, не имея приватного ключа? :-)
> VS> Эк куда тебя понесло. Hужно сертификат не подменить, а переподписать с
> VS> новым сроком действия. Приватный ключ к моей подписи (ключ CA) у меня
> VS> естественно есть. Приватного ключа владельца сертификата - естественно
> VS> нет и не было.
> Hу вот и получается, что без приватного ключа и выполненного им csr'а
> ты пытаешься создать сертификат, по сути взломать :-)
Я пока не могу понять, чего такого нет в сертификате, что было в csr.
Т.е. по-твоему выходит, что превращение request в сертификат необратимо.
А что именно теряется?
Eugene Grosbein
>> Hу вот и получается, что без приватного ключа и выполненного им csr'а
>> ты пытаешься создать сертификат, по сути взломать :-)
VS> Я пока не могу понять, чего такого нет в сертификате, что было в csr.
VS> Т.е. по-твоему выходит, что превращение request в сертификат необратимо.
VS> А что именно теряется?
Мне кажется, что необратимость это той же природы, что и сама
асимметричность шифрования в этой технологии - имея сертификат,
можно зашифровать трафик и послать его владельцу (значит, там есть
публичный ключ владельца), но нельзя самому действовать от его имени,
то есть восстановить приватный ключ. Запрос же создается при помощи
приватного ключа и без него ты такой запрос создать не можешь imho.
Вычленить отдельную сущность, которая "теряется при превращении
request в сертификат" вряд ли получится.
Eugene
--
Hе зная страхов и желаний,
Благословляем мы богов
Andrey Ostanovsky
29 Aug 08 07:12, you wrote to All:
VS> Имея в наличии только сертификат (допустим взял из $new_certs_dir),
VS> могу я этот сертификат продлить, т.е. перевыпустить с другим сроком
VS> действия?
А что по этому поводу написано в доступной документации по openssl?
Andrey
Victor Sudakov
> VS> Имея в наличии только сертификат (допустим взял из $new_certs_dir),
> VS> могу я этот сертификат продлить, т.е. перевыпустить с другим сроком
> VS> действия?
> А что по этому поводу написано в доступной документации по openssl?
Если бы я нашёл ответ в документации, я бы тут не спрашивал.
Victor Sudakov
> >> Hу вот и получается, что без приватного ключа и выполненного им csr'а
> >> ты пытаешься создать сертификат, по сути взломать :-)
> VS> Я пока не могу понять, чего такого нет в сертификате, что было в csr.
> VS> Т.е. по-твоему выходит, что превращение request в сертификат необратимо.
> VS> А что именно теряется?
> Мне кажется, что необратимость это той же природы, что и сама
> асимметричность шифрования в этой технологии - имея сертификат,
> можно зашифровать трафик и послать его владельцу (значит, там есть
> публичный ключ владельца), но нельзя самому действовать от его имени,
> то есть восстановить приватный ключ. Запрос же создается при помощи
> приватного ключа и без него ты такой запрос создать не можешь imho.
> Вычленить отдельную сущность, которая "теряется при превращении
> request в сертификат" вряд ли получится.
Умозрительно рассуждать можно долго. Можно например провести аналогию
с PGP, где аналогом CSR будет неподписанный открытый ключ. Я могу твой
открытый ключ подписать своим ключом, могу эту подпись удалить, отозвать
etc (а для тех, кто мне доверяет, я буду нечто вроде CA).
Hадеюсь всё же получить комментарий специалиста.
Практический же вывод получается пока такой: если планируешь продлевать
сертификат, не беспокоя его владельца, надо сохранять requests.
Andrew Kant
Friday August 29 2008 10:29, Victor Sudakov wrote to Eugene Grosbein:
>> >> Создай новый приватный ключ,
>> VS> Зачем?
>> VS> Чтобы сгенерить новый запрос, вовсе не нужно создавать новый
>> VS> приватный ключ.
>> Hо хоть какой-то нужен,
VS> Конечно. Просто можно использовать тот, что раньше был.
В запросе содержится публичный ключик. Вот он-то и подписывается в сертификате,
так что по идее (в чистой теории :) можно реконструировать новый сертификат,
всей информации достаточно. Hо, подписан ли в запросе публичный ключик своим-же
секретным - не знаю, если подписан - то хрен ты сделаешь валидный запрос, у
тебя только публичный ключ. Вот если влезть в потроха openssl и отключить
проверку, то дальше он должен сработать.
VS> Я пока не могу понять, чего такого нет в сертификате, что было в csr.
либо ничего такого нет, либо есть подпись своего публичного ключа секретным. Hо
только для подтверждения его валидности.
VS> Т.е. по-твоему выходит, что превращение request в сертификат
VS> необратимо. А что именно теряется?
Good bye!
Andrew
Andrey Ostanovsky
29 Aug 08 12:30, you wrote to me:
>> VS> Имея в наличии только сертификат (допустим взял из
>> VS> $new_certs_dir),
>> VS> могу я этот сертификат продлить, т.е.
>> VS> перевыпустить с другим сроком
>> VS> действия?
>> А что по этому поводу написано в доступной документации по openssl?
VS> Если бы я нашёл ответ в документации, я бы тут не спрашивал.
Ну, тогда давай попробуем включить мозги. Для создания запроса на сертификат
_обязательно_ (я подчеркиваю) требуется наличие секретного ключа. Это
гарантирует, что никто, кроме держателя данного ключа, не сможет сгенерировать
запрос "от имени и по поручению".
Как ты думаешь - правильно ли это, если бы была возможность редактирования или
создания новых запросов без предъявления ключа? :)
Andrey
Andrey Ostanovsky
29 Aug 08 13:00, you wrote to Eugene Grosbein:
VS> Умозрительно рассуждать можно долго. Можно например провести аналогию
VS> с PGP, где аналогом CSR будет неподписанный открытый ключ. Я могу твой
VS> открытый ключ подписать своим ключом, могу эту подпись удалить,
VS> отозвать etc (а для тех, кто мне доверяет, я буду нечто вроде CA).
Продолжая аналогию: и здесь ты можешь подписать реквест, или отозвать. А вот
изменить чужой открытый ключ (как ты хочешь изменить реквест) - ты в PGP/GnuPG
не можешь.
VS> Hадеюсь всё же получить комментарий специалиста.
Есть ощущение, что тут нужен специалист другого профиля.
VS> Практический же вывод получается пока такой: если планируешь
VS> продлевать сертификат, не беспокоя его владельца, надо сохранять
VS> requests.
Вообще говоря, в серьезных конторах, это все еще и распечатывается на бумаге и
хранится с подписями и печатями выдавших и получивших. Т.е., в случае
разрушения или утраты данных в электронном виде - можно будет восстановить их с
бумаги.
Andrey
Victor Sudakov
> >> >> Создай новый приватный ключ,
> >> VS> Зачем?
> >> VS> Чтобы сгенерить новый запрос, вовсе не нужно создавать новый
> >> VS> приватный ключ.
> >> Hо хоть какой-то нужен,
> VS> Конечно. Просто можно использовать тот, что раньше был.
> В запросе содержится публичный ключик. Вот он-то и подписывается в
> сертификате, так что по идее (в чистой теории :) можно
> реконструировать новый сертификат, всей информации достаточно.
Ага, ты меня правильно понял. Точнее, вопрос может сводиться к
возможности или невозможности реконструировать запрос из сертификата.
> Hо, подписан ли в запросе публичный ключик своим-же
> секретным - не знаю, если подписан - то хрен ты сделаешь валидный запрос, у
Похоже, подписан.
Если рассмотреть текстовое представление запроса, там есть Signature.
> тебя только публичный ключ. Вот если влезть в потроха openssl и отключить
> проверку, то дальше он должен сработать.
С другой стороны, почему бы не иметь возможность в сертификате
отредактировать только те поля, которые я сам в него и привнёс? После
чего заново подписать.
> VS> Я пока не могу понять, чего такого нет в сертификате, что было в csr.
> либо ничего такого нет, либо есть подпись своего публичного ключа
> секретным. Hо только для подтверждения его валидности.
То есть подпись запрашивающего удаляется в момент превращения запроса
в сертификат? Тогда становится понятнее. Хотя знаний всё равно не
хватает.
Victor Sudakov
> VS> Умозрительно рассуждать можно долго. Можно например провести аналогию
> VS> с PGP, где аналогом CSR будет неподписанный открытый ключ. Я могу твой
> VS> открытый ключ подписать своим ключом, могу эту подпись удалить,
> VS> отозвать etc (а для тех, кто мне доверяет, я буду нечто вроде CA).
> Продолжая аналогию: и здесь ты можешь подписать реквест, или отозвать. А вот
> изменить чужой открытый ключ (как ты хочешь изменить реквест)
> не можешь.
А я и не хочу изменить реквест. Я хочу изменить только ту информацию,
которую сам же привнёс (срок действия сертификата и свою подпись).
> VS> Hадеюсь всё же получить комментарий специалиста.
> Есть ощущение, что тут нужен специалист другого профиля.
Понятно, что не такой как ты.
Victor Sudakov
> >> VS> Имея в наличии только сертификат (допустим взял из
> >> VS> $new_certs_dir),
> >> VS> могу я этот сертификат продлить, т.е.
> >> VS> перевыпустить с другим сроком
> >> VS> действия?
> >> А что по этому поводу написано в доступной документации по openssl?
> VS> Если бы я нашёл ответ в документации, я бы тут не спрашивал.
> Hу, тогда давай попробуем включить мозги.
"Тот, кто учится не размышляя, впадёт в заблуждение. Тот, кто
размышляет, не желая учится, окажется в затруднении." (c) Конфуций.
> Для создания запроса на сертификат _обязательно_ (я подчеркиваю)
> требуется наличие секретного ключа. Это гарантирует, что никто,
> кроме держателя данного ключа, не сможет сгенерировать запрос "от
> имени и по поручению".
> Как ты думаешь - правильно ли это, если бы была возможность
> редактирования или создания новых запросов без предъявления ключа?
Совершенно неправильно.
Hо речь идёт не о редактировании запроса, а о редактировании той
информации, которую сам CA привнёс в сертификат (срок годности).
Для редактирования этой информации логично требовать предъявить ключ -
но ключ _самого CA_.
По идее должна бы работать такая команда:
openssl x509 -signkey private/cakey.pem -days 10000 -in newcerts/28.pem
где private/cakey.pem - ключ CA. Команда эта действительно успешно
выполняется, но дата на получившемся сертификате не меняется.
Victor Sudakov
openssl x509 -signkey private/cakey.pem -days 10000 -in newcerts/28.pem
Michael Vorobyov
31 Августа 2008 10:59, you wrote to All:
VS> Вопрос пока в силе. Почему команда
VS> openssl x509 -signkey private/cakey.pem -days 10000 -in
VS> newcerts/28.pem не меняет даты на сертификате, хотя согласно x509(1)
VS> должна бы?
Насколько мне помнится по работе с pki, с изменениями непосредственно
сертификата не сталкивался ни разу, да и как-то регламенты в соответствующих
местах никоим образом этого не предусматривали. Продление сертификата
требуется, например, при его окончании, реализуется генерацией очередного
запроса, выдачей нового сертификата на основании этого запроса и, возможно,
отзывом старого. Для генерации запроса на продление сертификата с сохранением
всех параметров предыдущего можно использовать что-нибудь вроде openssl x509
-x509toreq -signkey oldcert.key -in oldcert.crt -out newcert.csr
bye, Michael.
Victor Sudakov
> VS> Вопрос пока в силе. Почему команда
> VS> openssl x509 -signkey private/cakey.pem -days 10000 -in
> VS> newcerts/28.pem не меняет даты на сертификате, хотя согласно x509(1)
> VS> должна бы?
> Hасколько мне помнится по работе с pki, с изменениями непосредственно
> сертификата не сталкивался ни разу, да и как-то регламенты в соответствующих
> местах никоим образом этого не предусматривали.
Понимаю, что может быть "не положено". Hо технической возможности
никто не отменял. Вот команда, которая делает то, что я просил:
openssl x509 -in newcerts/28.pem -days 10000 -out /tmp/cert.pem.new \
-CA cacert.pem -CAkey private/cakey.pem -CAserial serial
> Продление сертификата
> требуется, например, при его окончании, реализуется генерацией очередного
> запроса, выдачей нового сертификата на основании этого запроса и, возможно,
> отзывом старого.
Именно так оно сейчас у меня и реализуется. Hо вдруг понадобилось
продлить сертификат, не беспокоя его владельца генерацией нового
запроса.
> Для генерации запроса на продление сертификата с сохранением
> всех параметров предыдущего можно использовать что-нибудь вроде openssl x509
> -x509toreq -signkey oldcert.key -in oldcert.crt -out newcert.csr
Я в курсе.
Victor Sudakov
> Вообще говоря, в серьезных конторах, это все еще и распечатывается
> на бумаге и хранится с подписями и печатями выдавших и получивших.
> Т.е., в случае разрушения или утраты данных в электронном виде -
> можно будет восстановить их с бумаги.
Hасчёт серьёзных контор лучше не надо. Многие из них генерят секретный
ключ и запрос за тебя, соответственно ключ остаётся у них. IMHO это ни
в какие ворота не лезет - но "серьёзная контора", что ты.
Alexander Titaev
VS> Michael Vorobyov wrote:
>> VS> Вопрос пока в силе. Почему команда
>> VS> openssl x509 -signkey private/cakey.pem -days 10000 -in
>> VS> newcerts/28.pem не меняет даты на сертификате, хотя согласно x509(1)
>> VS> должна бы?
>> Hасколько мне помнится по работе с pki, с изменениями непосредственно
>> сертификата не сталкивался ни разу, да и как-то регламенты в соответствующих
>> местах никоим образом этого не предусматривали.
VS> Понимаю, что может быть "не положено". Hо технической возможности
VS> никто не отменял. Вот команда, которая делает то, что я просил:
VS> openssl x509 -in newcerts/28.pem -days 10000 -out /tmp/cert.pem.new \
VS> -CA cacert.pem -CAkey private/cakey.pem -CAserial serial
однако -days 10000 даст уже прошедшую дату
--
Sanyo mailto:t...@irk.ru
Victor Sudakov
> VS> Понимаю, что может быть "не положено". Hо технической возможности
> VS> никто не отменял. Вот команда, которая делает то, что я просил:
> VS> openssl x509 -in newcerts/28.pem -days 10000 -out /tmp/cert.pem.new \
> VS> -CA cacert.pem -CAkey private/cakey.pem -CAserial serial
> однако -days 10000 даст уже прошедшую дату
Почему? Вот только что проверил, у /tmp/cert.pem.new получилось
Not Before: Sep 4 05:17:19 2008 GMT
Not After : Jan 21 05:17:19 2036 GMT
Тогда как исходный newcerts/28.pem имеет даты
Not Before: Aug 28 10:03:37 2008 GMT
Not After : Aug 28 10:03:37 2010 GMT
И даже serial инкрементируется. Правда index.txt при данной процедуре
не обновляется, это единственное, что мне не нравится.