Comments 35
Вы забыли упомянуть Letsencrypt, хотя статью начали с WoSign/StartSSL, которые известны прежде всего бесплатными сертификатами. :-)
Использую Let's encrypt уже вполне давно, полет нормальный.
Ну Вы же понимаете, что компании, в том числе, занимающейся продажей SSL-сертификатов это экономически невыгодно.
Коллега, экономического заговора здесь нет. Мы просто стараемся делиться чем-то полезным.
Действительно, один из вариантов получения SSL-сертификатов — воспользоваться бесплатными сервисами. Как верно заметил symbix, мы упомянули WoSign, например. Однако, будем честны, применимость бесплатных сертификатов ограничена — далеко не все компании готовы ими пользоваться.
Действительно, один из вариантов получения SSL-сертификатов — воспользоваться бесплатными сервисами. Как верно заметил symbix, мы упомянули WoSign, например. Однако, будем честны, применимость бесплатных сертификатов ограничена — далеко не все компании готовы ими пользоваться.
применимость бесплатных сертификатов ограничена — далеко не все компании готовы ими пользоваться
Какова причина?
Сложность настройки и поддержки автообновлений сертификатов и отслеживание мест где он не обновился. Плюс специфичный софт в который просто так сертификат не пропишешь. Т.е. если у тебя будет где-то сбоить обновление — на это уйдут затраты времени работника при разборе проблемы. В этом случае проще и дешевле будет купить сертификат на 5-10 лет и вспоминать про его обслуживание только в конце срока действия.
С долгосрочными сертификатами есть немалая вероятность забыть о необходимости его обновления, если отсутствуют процедуры напоминания. А это чревато внезапной неработоспособностью массы приложений, которые их используют. Так что краткосрочный сертификат от того же Let's Encrypt при правильно настроенной процедуре обновления убирает этот риск.
Есть ещё и другие риски долгосрочных сертификатов
Есть ещё и другие риски долгосрочных сертификатов
Это несомненно так, но хорошо, что есть выбор из разных вариантов — каждый может пользоваться тем, что удобнее для него
Если у вас унифицированая инфраструктура с небольшим набором систем, то в летсенкрипт смысл есть (т.е. например у вас только иис и windows server 2012r2 или там RHEL7 со стандартным набором пакетов). Но если у вас например холдинг компаний разработчиков, где набор разномастных систем которые смотрят наружу (win2003/2008/2012к2+iis, vpn'ы разные, rdpaps, S4B, разных кастомизированных линухов вобще можно не считать) просто зашкаливает и небольшой инженерный отдел, то по трудозатратам на внедрение и поддержку лучше наиболее долгоиграющие сертификаты (в идеале лет на 10) — получил сертификат, воткнул, завел в мониторинг, забыл про систему до момента заявки. Реальная экономия времени на раскуривание — а какой готовый скрипт летсэнкрипта в данной системе заработает и не отвалится ли он скажем через год, два, три (у меня например отвалился через пол года после автоматического обновления скрипта автопродления) и если отвалится — его все равно придется чинить либо вам либо другому человеку. Чтобы не забыть про сроки — воткнуть в тот-же заббикс проверку срока в готовый шаблон.
Долгоиграющий сертификата имеют еще один плюс — если он реально на большой срок, то скорее всего бизнес уже в какой-то момент перестроится и вам еще раз придется их внедрять уже в новые системы. И проще опять же внедрить либо его либо купить новый долгоиграющий, чем опять разбираться в готовых скриптах (вы же не будете писать его сами).
Не надо краткосрочные сертификаты возводить в абсолют, они конечно бесплатны, по идее более безопасны и для многих проектов прекрасно подойдут. Но вот затраты времени на их внедрение и поддержку это весьма неоднозначно. Стоимость 1 дня работы инженера гораздо больше чем 1 сертификат на 5-10 лет установленный 1 раз за 10 минут.
Долгоиграющий сертификата имеют еще один плюс — если он реально на большой срок, то скорее всего бизнес уже в какой-то момент перестроится и вам еще раз придется их внедрять уже в новые системы. И проще опять же внедрить либо его либо купить новый долгоиграющий, чем опять разбираться в готовых скриптах (вы же не будете писать его сами).
Не надо краткосрочные сертификаты возводить в абсолют, они конечно бесплатны, по идее более безопасны и для многих проектов прекрасно подойдут. Но вот затраты времени на их внедрение и поддержку это весьма неоднозначно. Стоимость 1 дня работы инженера гораздо больше чем 1 сертификат на 5-10 лет установленный 1 раз за 10 минут.
И чем же платный DV-сертификат отличается от бесплатного?
Некоторые настолько не готовы, что предпочитают самоподписанные сертификаты, и предлагают пользователям ставить из root ca. Это вообще за гранью, но такова реальность.
Вот именно поэтому letsencrypt — это отлично. Хватит уже воздухом торговать. Выдача DV не стоит почти ничего. Цена даже в 10-15 рублей окупит затраты на сервер, запускающий openssl в автоматическом режиме. По сути, торговля воздухом. А тут-то вообще перепродажа воздуха, зарегистрировались партнером и все, затрат вообще ноль. Польза только в том, что налоги плятят :-)
letsencrypt работает, но менять сертификат каждые три месяца и нет (или не нашел) как поддомен поставить и как с винды нормально взять сертификат.
Сертификат меняется автоматически, вот список клиентов: https://letsencrypt.org/docs/client-options/ — наверняка под виндой что-то из них да работает. С субдоменами — если достаточно фиксированного списка, то можно прописать сотню с лишним altName-ов, если нужны wildcard — обещают в январе.
Если бы letsencrypt выдавал сертификаты на 5-10 лет то это было бы отлично. Но, как я понял, это в корне противоречит всей их идее.
Поэтому, спасибо конечно, но воспользуемся услугами других.
Но про торговлю воздухом (DV-сертификаты) полностью согласен. За такое деньги если и брать то чисто символические.
Поэтому, спасибо конечно, но воспользуемся услугами других.
Но про торговлю воздухом (DV-сертификаты) полностью согласен. За такое деньги если и брать то чисто символические.
1. https://letsencrypt.org/2015/11/09/why-90-days.html
2. «CAB Forum Ballot 193, which was proposed by Entrust, will place a new limit on maximum lifetime for all publicly trusted SSL certificates. The new limit will be 825 days – that’s two years with some padding built in to allow for renewal and replacement – and will come into effect on March 1st of 2018.
Currently, the maximum SSL certificate validity period is 3 years (39 months to be exact), and CAs will continue to issue such certificates until the new ballot comes into effect.»
2. «CAB Forum Ballot 193, which was proposed by Entrust, will place a new limit on maximum lifetime for all publicly trusted SSL certificates. The new limit will be 825 days – that’s two years with some padding built in to allow for renewal and replacement – and will come into effect on March 1st of 2018.
Currently, the maximum SSL certificate validity period is 3 years (39 months to be exact), and CAs will continue to issue such certificates until the new ballot comes into effect.»
Невероятно. Думал ничто их не прошибет. Неужели дождемся и сертификатов на 10 лет?
Эмм, не понял, откуда следует радость и ожидание появления сертификатов на 10 лет.
Форум сократил максимальный лайфтайм с трёх лет до двух лет. Изначально хотели сократить до года, но там какие-то интересные кейзы вылезли (не разбирался), и чтобы долго не спорить, сошлись на двух годах.
Тенденция к сокращению лайфтайма есть, и она правильная, ибо сертификаты должны быть довольно короткие, по причинам, изложенным в документе от let's encrypt. И если причину секурити можно (и даже нужно) побеждать всякими oscp, hpkp, dane etc, то вторую причину (давление на автоматизацию реньювала) никуда не денешь. А отсутствие автоматизации настолько угроза для всей системы TLS, что если грубо не давить на общество, форсируя эту самую автоматизацию, то развал всей системы видится очень так неиллюзорно и в довольно краткосрочной перспективе (пяток лет).
Форум сократил максимальный лайфтайм с трёх лет до двух лет. Изначально хотели сократить до года, но там какие-то интересные кейзы вылезли (не разбирался), и чтобы долго не спорить, сошлись на двух годах.
Тенденция к сокращению лайфтайма есть, и она правильная, ибо сертификаты должны быть довольно короткие, по причинам, изложенным в документе от let's encrypt. И если причину секурити можно (и даже нужно) побеждать всякими oscp, hpkp, dane etc, то вторую причину (давление на автоматизацию реньювала) никуда не денешь. А отсутствие автоматизации настолько угроза для всей системы TLS, что если грубо не давить на общество, форсируя эту самую автоматизацию, то развал всей системы видится очень так неиллюзорно и в довольно краткосрочной перспективе (пяток лет).
Тогда жопа. Надежды на развал такой системы автоматизации мало.
А можно раскрыть мысль про развал системы TLS по причине отсутствия автоматизации?
А можно раскрыть мысль про развал системы TLS по причине отсутствия автоматизации?
На данный момент индустрия может бороться с атаками только усложнением процедур. Чем процедура сложнее — тем её сложнее делать человеку, соответственно, без автоматизации либо это не будут делать (у скольки людей настроен и работает hpkp? «работает» — это когда можно не бояться окончания срока действия сертификата и когда можно отозвать сертификат без проблем с клиентами, учитывая все кешинги, CDN-ы и подобные вещи), либо будут делать с ошибками (типичный пример — hsts).
Одной из проблем всей системы является централизация, то есть вот те самые корневые CA, которым договорились доверять. Уже сейчас это реально проблема как со стороны секурити (собственно, dane, hpkp, ocsp stapling и так далее одной из причин имеют ту самую централизацию), так и со стороны хайлоада. Одной из основных нерешённых вещей является процедура отзыва сертификата (вероятность компрометации приватного ключа вовсе не такая уж маленькая, как многие думают, а текущая тенденция всё виртуализировать/контейнезировать только повышает её), короткий лайфтайм — это попытка решить эту проблему наиболее простым способом.
Одной из проблем всей системы является централизация, то есть вот те самые корневые CA, которым договорились доверять. Уже сейчас это реально проблема как со стороны секурити (собственно, dane, hpkp, ocsp stapling и так далее одной из причин имеют ту самую централизацию), так и со стороны хайлоада. Одной из основных нерешённых вещей является процедура отзыва сертификата (вероятность компрометации приватного ключа вовсе не такая уж маленькая, как многие думают, а текущая тенденция всё виртуализировать/контейнезировать только повышает её), короткий лайфтайм — это попытка решить эту проблему наиболее простым способом.
Интересно было прочесть.
Вот только, разве, при обновлении сертификата у LE меняется первичный ключ?
Вот только, разве, при обновлении сертификата у LE меняется первичный ключ?
Let's Encrypt не имеет никакого отношения к приватному ключу. Как и всегда, приватный ключ (да и CSR целиком, да и коммуникации по ACME-протоколу, ибо приватный ключ никогда не должен покидать той машины, на которой он генерился, то есть если ты что-то подописываешь, то должен это делать на той машине, на которой генерил ключ) должен генериться на том сервере, с коротого происходит запрос на выписку сертификата.
1. https://letsencrypt.org/how-it-works/
2. https://letsencrypt.org/docs/faq/ + поиск по слову private key
При желании можно использовать приватный ключ повторно, но единственная причина так делать — отсутствие автоматизации. Ну и естественно это ухудшает безопасность — если мы постоянно используем один и тот же ключ, посылая пакетики известной структуры, то сложность взлома шифрования уменьшается.
1. https://letsencrypt.org/how-it-works/
2. https://letsencrypt.org/docs/faq/ + поиск по слову private key
При желании можно использовать приватный ключ повторно, но единственная причина так делать — отсутствие автоматизации. Ну и естественно это ухудшает безопасность — если мы постоянно используем один и тот же ключ, посылая пакетики известной структуры, то сложность взлома шифрования уменьшается.
Ещё letsencrypt с 2018 собирается выдавать wildcard, что ещё подрежет рынок
none
UFO just landed and posted this here
Первый тип сертификатов — это сертификаты с проверкой домена (Domain Validated). Они подходят для некоммерческих сайтов, поскольку подтверждают только обслуживающий сайт веб-сервер, на который осуществлён переход. DV-сертификат не содержит идентифицирующей информации в поле имени организации. Обычно там числится значение «Persona Not Validated» или «Unknown».
Обычно там вообще нет полей o, ou, l, c.
Этот вид сертификата самый дешевый и популярный, но не считается полностью безопасным, поскольку содержит информацию лишь о зарегистрированном доменном имени. Поэтому они часто используются для защиты во внутренних сетях или на небольших веб-сайтах. Однако есть и исключения. Например, компании Google не нужно доказывать общественности, что www.google.com принадлежит ИТ-гиганту. Поэтому они используют простые сертификаты с проверкой домена (как и amazon.com).
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 6831279663967598973 (0x5ecd94a92423797d)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Google Inc, CN = Google Internet Authority G2
Validity
Not Before: Jul 19 11:55:57 2017 GMT
Not After : Oct 11 11:31:00 2017 GMT
Subject: C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c2:d1:c8:7a:f6:62:1e:71:c2:1c:29:f5:d3:61:
d8:ae:59:14:b6:89:75:4f:8c:ce:a6:fa:ee:89:c1:
0d:2b:34:c6:94:cb:29:d9:e0:3e:e6:c4:bc:da:9c:
e0:9a:bd:ec:20:08:ab:3e:9e:dd:7c:45:9e:64:64:
ea:1f:13:67:5f:97:56:0c:9a:73:cb:0f:00:24:d9:
24:37:19:10:53:b2:5b:4a:44:e3:6d:a3:b5:1b:f4:
02:b9:13:d6:4d:f9:97:e0:f1:51:9f:c5:a7:6e:4f:
78:2a:13:7b:5e:94:f0:87:12:88:97:1d:f3:61:47:
4f:aa:49:73:21:83:7e:4a:5e:05:3d:10:84:93:2a:
8e:ed:a8:f3:a1:66:0f:34:a9:29:2a:22:d9:0f:1a:
44:6c:4c:e7:f2:c4:62:eb:ce:55:25:89:1f:2a:c5:
75:6e:86:1a:3f:71:04:21:33:47:a0:80:7c:35:ef:
a8:e0:17:49:5a:b0:6e:ef:c6:6c:7d:a8:72:0b:2f:
1f:97:e7:1a:34:b0:9a:db:e0:3e:04:e3:1a:e6:18:
42:12:cb:95:43:01:2d:1f:82:ba:fb:23:37:8d:55:
ac:a9:4f:36:66:cd:3f:6c:7b:f5:3b:4e:36:36:0d:
58:d0:38:7a:be:d2:f7:a0:15:0b:a8:93:41:26:c7:
38:e9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:www.google.com
Authority Information Access:
CA Issuers - URI:http://pki.google.com/GIAG2.crt
OCSP - URI:http://clients1.google.com/ocsp
X509v3 Subject Key Identifier:
8D:2E:25:9F:E5:C7:E5:26:3B:FE:30:21:51:29:D8:E1:5B:0D:70:3D
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.11129.2.5.1
Policy: 2.23.140.1.2.2
X509v3 CRL Distribution Points:
Full Name:
URI:http://pki.google.com/GIAG2.crl
Signature Algorithm: sha256WithRSAEncryption
65:b2:69:e3:c3:9d:da:3c:07:9f:68:cc:10:35:8b:ca:e8:a0:
58:14:75:a0:5f:89:f2:7b:43:90:1f:12:6e:f7:1c:c7:92:21:
93:e0:79:2e:32:56:55:bb:d4:1a:48:e5:0f:00:61:41:b6:94:
bc:1b:94:3e:0c:a1:15:d3:29:b7:02:fa:60:9e:ce:1c:02:46:
43:08:dd:96:83:a2:0a:84:10:89:fd:aa:69:36:e6:62:ed:58:
f1:a9:06:5f:1b:94:74:67:7b:2a:6b:66:bd:1e:88:77:f9:4d:
e6:b9:ef:8f:dd:3e:bb:5c:3f:ec:71:32:6e:0c:ca:bc:83:ca:
af:09:a8:6d:07:34:b0:a3:5f:16:d4:d7:70:c2:3a:2a:21:62:
54:b4:34:40:25:ec:7a:d7:d5:e1:13:03:11:c3:7a:44:d4:51:
2b:57:84:36:ae:d4:64:09:3b:65:7b:00:47:0f:10:7f:6b:b1:
e4:85:b2:b3:27:04:80:25:7b:c2:04:ca:ac:b8:6d:34:f5:d4:
fd:bc:40:00:01:0d:1f:a6:a8:f1:12:e2:59:3f:86:b0:27:90:
96:d1:7b:13:ba:f2:0f:05:d8:6c:39:d4:a6:71:6d:11:17:5c:
31:0f:b1:0f:ec:32:59:a8:9b:af:a5:92:48:9d:48:c8:46:86:
97:6a:93:bfВ общем, пишите статьи, так хоть разберитесь в том о чём пишите хотя бы минимально.
Для amazon.com полный дамп не привожу, но он тоже OV: /C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=www.amazon.com
Не вполне по теме, но раз уж тут упомянули LetsEncrypt.
Есть некий сайт, хостится дома, на условно белом ip. А-запись DNS размещена у Cloudflare. Когда LetsEncrypt пытается связаться с сайтом по ip для выдачи сертификата, Cloudflare отдаёт ему другой ip и всё идёт прахом — handshake failure. Как побороть?
Есть некий сайт, хостится дома, на условно белом ip. А-запись DNS размещена у Cloudflare. Когда LetsEncrypt пытается связаться с сайтом по ip для выдачи сертификата, Cloudflare отдаёт ему другой ip и всё идёт прахом — handshake failure. Как побороть?
Самое простое — пройти валидацию через DNS, см. ACME DNS Challenge.
Тут лучше таки разобраться с Cloudflare, и получить сертификаты для входных точек у них самих. Ибо коннект пользователя будет на CDN entry point, и сертификат нужен именно на тот домен.
Плюс, если вам нужен сертификат только для своего хоста, чтобы cf ходил по защищенному каналу — у них есть origin cert, который подписывают они сами.
В какой организации по рекомендуете получить бесплатный сертификат для NAS?
Sign up to leave a comment.
Немного о SSL-сертификатах: Какой выбрать и как получить