Генерация закрытого ключа для https

Очень странно всё. Обычно даётся 4 файла:

• закрытый ключ
• сертификат к нему
• промежуточный сертификат
• корневой сертификат.

И тебе только может быть нужно собрать fullchain.pem: https://elma365.com/ru/help/platform/fullchain-sertificate.html

Т.е. поместить в один текстовый файл содержимо

сертификат домена
промежуточный сертификат
корневой сертификат

один за другим.

Если есть внешний IP и привязка домена к нему и полный доступ до консоли - установи certbot и получи сам Let`s Encrypt сертификат.

Не хочется let Encript, ведь полгода действует настоящий, да и стоит он не дорого. Боюсь что let encript может негативно сказаться на репутации и ранжировании.

Очень странно всё. Обычно даётся 4 файла:

Дали как раз четыре, я вот думаю, что как раз «ваш сертификат» в их терминологии и есть закрытый ключ. Тогда получается что генерировать ничего не надо?

сертификат к нему

Насколько я понял, нет такого понятия как «сертификат к ключу». Это запрос на получение ключa Certificate Signing Request, который сохраняют в файле с расширением csr. Последнее r как раз означает request.

Короче насколько я понял, приватный ключ это и есть «ваш сертификат», а запрос доступа к нему они сами сгенерировали. Я пока так думаю.

Дословно получается «запрос подписанного сертификата»

В рамках SSL или любого шифрования, а SSL - это шифрование. Есть открытая и закрытая часть шифра.

Сертификат - это открытая часть, a private.key - закрытая часть.

Данные, которые отправляются на сервер клиент шифрует открытой частью и отправляет на сервер и сервер закрытой частью ключа их расшифровывает.

Перед установкой SSL соединения происходит процедура обмена открытой частью ключей. Т.е. WEB-клиент (браузер) так же отправляет свой открытый ключ и расшифровывает своим закрытым полученные от WEB-сервера данные.

То есть, как я понял запрос уже есть, а приватного ключа нет, так? Но по инструкции должно быть наоборот, ключ должен быть, а запрос должен быть сгенерирован.

Приватный ключ остаётся у них? Весьма странно, учитывая, что без него CSR не сгенерировать, а значит обновления сертификата тебе не видать.

Или может быть «ваш сертификат» - это и есть ключ?

Смотри первые строчки в файлах, что ли. Там -----BEGIN ...-----, если регистратор не упорот и не выдал их в бинарном виде (тогда их надо сконвертировать в PEM).

везде —–BEGIN CERTIFICATE—– кроме реквеста. 3 сертификата.

если понятие «ваш сертификат» это не ключ, тогда что это?

а значит обновления сертификата тебе не видать

Наверное так и задумано, это дается бесплатно на полгода

Ну, и что?

тогда что это?

Очевидно — сертификат. (%

И ничего )

Боюсь что let encript может негативно сказаться на репутации и ранжировании.

Если ты пытаешься прикрутить SSL крупной конторе — это имеет смысл только в плане гарантий что корневой сертификат не отзовут раньше времени (по причине компрометации или закрытии конторы по банкротству или ещё каким причинам; конторы, которые выпускают сертификаты за деньги не схлопнутся внезапно). На репутацию влияет контент и то что сертификат не самоподписанный (самоподписанный сертификат в наше время равносилен его отсутствию — доверия такому сертификату быть не может, никто не может убедиться что твой "левый" сертификат выпустил именно ты, а не взломщик твоего сервера, который на нём же новый сертификат и выпустил, чтобы сервить малварь). На ранжирование влияет только контент сайта.

Насколько я понимаю, регистратор дает настоящий сертификат

То что на ранжирование влияет только контент это нонсенс. Тогда бы обычные информационные сайты вообще не использовали бы шифрование. Давно уже принято, что шифрование влияет на ранжирование

Вот:

Защищенный протокол входит в перечень факторов ранжирования в Яндекс и Google.

https://www.web-canape.ru/business/kak-ustanovit-ssl-sertifikat-i-perejti-na-https-poshagovaya-instrukciya/

То есть, как я понял запрос уже есть, а приватного ключа нет, так? Но по инструкции должно быть наоборот, ключ должен быть, а запрос должен быть сгенерирован.

в инструкции все правильно, что они прислали - а черт их знает. Может перепутали CSR и секретный ключ, может это бесплатный сыр и подразумевается, что они будут хранить секретный ключ и терминировать TLS где-то там у себя.

Или может быть «ваш сертификат» - это и есть ключ?

у секретного ключа в PEM-заголовке должно быть указано BEGIN PRIVATE KEY

Все присланное можно распарсить с помощью openssl:

$ openssl x509 -in cert.pem -noout -text # сертификат
$ openssl req -in cert.csr -noout -text # CSR
$ openssl pkey -in cert.key -noout -text # секретный ключ

Ты всё перепутал.

Во-первых, закрытый ключ не «даётся», а ты сам его генерируешь и никому не сообщаешь. Если кто-то хочет его тебе давать сам или хочет чтобы ты куда-то слал свой - услугами таких CA пользоваться точно не надо.

Во-вторых, не надо никаких certbot, это блоатварь, выбирай нормальный le-клиент, например acme-tiny.

Lets encrypt это очень даже настоящий сертификат. И действует он бессрочно, если ты правильно настроишь автообновление. А там, где тебе кто-то что-то присылает вручную - это ненужная возня раз в какое-то время. Ранжированию letsencrypt никак не повредит.

И повторю что писал выше - закрытый ключ ты должен генерировать сам и держать его в секрете.

CSR ты тоже генерируешь сам, на основе ключа. CSR уже не содержит секретных данных, его можно отправить в центр сертификации чтобы тебе выдали сертификат.

Во-вторых, не надо никаких certbot, это блоатварь, выбирай нормальный le-клиент, например acme-tiny.

в angie из коробки есть acme-модуль, причем с DNS-челенджем. Им и пользуюсь.

Вот зачем ты тут написал очередную бесполезную простыню? Автор не спрашивал как https-соединения работают.

А как же тогда они могли прислать BEGIN CERTIFICATE REQUEST? Он ведь должен на основе ключа генерироваться?

Наличие или отсутствие шифрования - влияет. То, что сертификат там подписан общепризнанным CA (а не самодельным) - влияет. LetsEncrypt - общепризнанный. Больше ничего не требуется.

Видимо имеется ввиду что через полгода ты им этот CSR назад пришлёшь чтобы они продлили сертификат.

Цепочка такая:

1. Приватный ключ. Его генерируешь ты, прямо на сервере где будет сайт, и никуда с этого сервера не уносишь. Он секретный. Права доступа ставишь такие чтобы его мог прочитать nginx при запуске и никто другой. Срока действия у него нет, если только ты не решишь сам его сменить (после кражи или подозрения на неё).

2. CSR - содержит всё, что нужно для выдачи тебе сертификата, в том числе ту часть ключа, которая не секретна. Ты его генерируешь на том же сервере где и ключ, но в отличие от ключа его можно без опасений слать куда угодно или даже опубликовать для скачивания всеми подряд где-нить. Ты его шлёшь центру сертификации. Срока действия у него тоже нет. Но если ты сменишь приватный ключ или списко своих доменов - CSR надо делать заново.

3. Сертификат - его генерирует центр сертификации на основе того CSR, который ты им прислал. Его нужно положить на тот же сервер чтобы nginx мог его прочитать и потом показывать всем браузерам которые к нему обратятся. Он тоже несекретный. Срок действия короткий, поэтому раз в сколько-то месяцев надо повторять процедуру.

Забей на них и сделай сертификат через letsencrypt.

В общем, нашел этот файл, его можно отдельно было скачать. Пока тему закрою.

Вот:

Защищенный протокол входит в перечень факторов ранжирования в Яндекс и Google.

И где там написано, что разные корневые сертификаты (если это не самоподписанные васянские сертификаты, с ними понятно) по-разному влияют на ранжирование?

Ты сам-то читаешь то, на что ссылаешься? (%

На ранжирование влияет только контент сайта.

ты сказал

На ранжирование влияет только контент сайта.

ты сказал

Если твой контент уникален, как он упадёт в выдаче?

хз

Выпускатель сертификата ни на что не влияет, вопрос только валидный или не валидный он. Плюс гугл один из спонсоров let's encrypt, так что не будет воевать против самого себя.

Боюсь что let encript может негативно сказаться на репутации и ранжировании.

Не так давно, от одного работодателя, услышал подобное, которое ему в ухо нашептал сео. Говорит, что сертификаты от Let’s Encrypt вообще плохо шифруют =)

Этого исключать нельзя. Если есть нормальный сертификат, зачем рисковать. Файл секретного ключа я в итоге нашел. Там все готово для установки настоящего сертификата.

В целом, я думаю, там есть какой то подвох. Если бы это был надежный сертификат, никто бы не стал покупать настоящие сертификаты. А для крупных компаний там стандарт сертификата еще выше.

Да ваще! И название какое-то совсем не пацанское, неуверенное какое-то «Let’s Encrypt», типа «а давайте», разве может крутой сертификат так назваться? Конечно нет! Настоящий мужыцкий сертификат должен называться хотя бы «Encrypt, motherfucker!» уж тогда! А для крупных компаний в конце ещё LTD GmbH ©®™

Так то мужики не пацаны, пацаны говорили мужики в поле пашут. Мужик это слуга вора, пацаны ни тех ни других не уважали. В РИ мужиками называли рабов, это пацану западло. Это все неправильно сейчас трактуется.

Encrypt, motherfucker нормальное название, к нему сразу доверие возникает. если не пацанское, то хотя бы ковбойское.

Мужик это слуга вора, пацаны ни тех ни других не уважали. В РИ мужиками называли рабов, это пацану западло.

Мне кажется, с таким рассуждением, заходя на форум, надо здороваться: - «Вечер в хату, бедолаги!»

В целом, я думаю, там есть какой то подвох. Если бы это был надежный сертификат

Хотелось бы услышать какие-то аргументы в плохую сторону Let’s Encrypt

Обычно у нормальных людей ты генерируешь КЛЮЧ И ЗАПРОС, запрос отправляешь, и тебе возвращают сертификат. Цепочка ЦА уже второстепенна (хотя ее как правило тоже присылают). А если твой ключ увидел кто-то кроме тебя, твой сертификат сразу считается cкомпрометированным - и все схемы не соотвествующие указанному это разводилово, надувалово и профанация