Как стать автором
Обновить

Комментарии 127

параноик во мне не может довериться китайскому удостоверяющему центру :(
А зря, потому что в приведённом примере мы засылаем ему запрос на сертификат, а закрытый ключ не «светим» (гененируем у себя). StartSSL же по умолчанию предлагает сгенерировать закрытый ключ на его стороне, что как бы ни разу не круто (с запросом на сертификат тоже можно, но нужно осмысленно нажать нужную ссылочку на одном из шагов).
Это не защищает от MitM атаки, в случае, если УЦ подписывает приватный ключ человека посередине, выдавая ему валидный для домена сертификат.
Китайский ЦА может выдать сертификат для вашего домена без вашего участия ;)
Собственно то же самое я и написал, только чуть более подробно.
Мхм. Мда, что-то я веткой промазал)
Поэтому многие говорят, что идея с УЦ в принципе ущербна. Ведь это может сделать любой УЦ. Прецеденты были. Зачем дискредитировать именно китайский УЦ? Я бы в текущей ситуации больше бы боялся именно американских и европейских…
А я не дискредитирую этот УЦ, а просто говорю, что опасность сохраняется даже если мы не светим свой закрытый ключ кому попало.
Осталось дождаться способов не доверять подобным «удостоверяющим центрам», раздающих сертификаты направо-налево.
Например, в FF не помогает удаление сертификатов центра WoSign CA Limited :(
Они, так же как и StartSSL, проверяют, что ты владеешь доменом (отсылают проверочный код на один из ящиков типа webmaster@your.domain) — вполне нормальная проверка для бесплатных сертификатов, совсем уж кому попало каких попало сертификатов не выдают. Зачем им не доверять?
Проверка владения доменом, которая есть у этих сервисов, не позволит сделать сертификат для чужого сайта, чтобы прослушивать его трафик. С другой стороны, если бы такой проверки не было, то злоумышленник мог бы и заплатить за сертификат. Ведь подделка сертификата какого-нибудь банка принесёт гораздо больше денег, чем стоимость сертификата. Так что платность совершенно не защита от взломщиков. А бесплатные сервисы делают хорошее дело, позволяя защититься даже некоммерческим проектам.
Проверка владения доменом
А бесплатные сервисы делают хорошее дело, позволяя защититься даже некоммерческим проектам.
А когда коммерческие проекты экономят на сертификатах — это нормально? Позор Хабрахабру, Госуслугам, банку Открытие и всем остальным организациям, использующим сертификаты проверки домена! Даже у меня на сайте с простенькой JS-игрой про Путина сертификат выдан после проверки документов организации. Вот DigiCert и Entrust молодцы, вообще не позволяют себе выдавать сертификаты Domain Validation.
Сайт совсем не обязательно может принадлежать организации. Часто важен лишь факт, что сайт находится на определённом сервере, а не то что сервер принадлежит какой-то организации. В той же игре мне совершенно наплевать какой организации она принадлежит — мне важно лишь, чтобы мой пароль не увели с помощью MTiM.

Вы слишком однобоко мыслите. Защищённость передачи информации нужна, но в меру. Это как советовать всем ездить на бронированных машинах. Да, безопасность повышается, только стоит в 10 раз дороже и жрёт уйму бензина, а большинству хватит и обычной машины. А в таком реальная потребность есть только у некоторых (инкассаторы, политики).

Вот для банков, да. Важно, потому что на кону могут стоять миллионы. А для того же хабра SSL нужен только чтобы пароли юзеров не уводили на бесплатном Wi-Fi.
Например, в FF не помогает удаление сертификатов центра WoSign CA Limited :(
Поздновато, но всё же отвечу. Вы цепочку доверия смотрели? Сайты отправляют промежуточный сертификат WoSign, выданный от корневого сертификата StartCom или Comodo. Пока вы доверяете StartCom и Comodo (самый популярный CA, не так давно даже обогнал Symantec), вы будете доверять WoSign.

Я сам крайне недоволен, но это факт.
у меня параноя по другому поводу: пускай я использую облачный сервер от провадере «X» — не может/будет ли он читать мою информацию на арендуемом сервере (ключи для шифрования трафика, ключи OpenVPN)?
Может. Но, скорее всего не будет, т. к. репутационные риски. Что, впрочем, не исключает недобросовестного сотрудника.
Что-то как-то… Еще и сервер настраивать… Я лучше уж раз в год буду у StartSSL продлевать.
Так для StartSSL тоже желательно так же настраивать, не?
Работает из коробки, только сертификаты указал. Там НЕОБХОДИМО настройку такую сделать.
Пожалуйста, дочитайте предложение до конца: «необходимо настроить…, чтобы запросы на авторизацию сертификатов не перенаправлялись при каждом соединении с вашим сайтом в Китай». Т.е. будет работать и без OCSP Stapling, но, возможно, медленно, потому что Китай далеко. StartSSL'я это тоже касается.
Да, простите, недочитал. Для StartSSL, кмк, это менее критично, чем для WoSign.
Картинками было бы понятнее.
Спасибо огромное, без этого комментария многое в процедуре оставалось непонятным.
>>Необходимо выбирать сертификаты, использующие SHA2.
Не силен в китайском, подскажите как это выбрать, не нашел эти параметры, в корзину попадает сертификат с SHA1?
Был выбор на каком-то шаге (уже после корзины), спрашивали язык сертификата и версию SHA.
Эмм, тоже не силен в китайском, а дает только для доменов второго уровня или поддомены тоже?
Лично я вижу смысл только в EV SSL сертификатах, когда название организации (владельца сайта) подсвечивается зеленой рамкой. Это относится к тем случаям, когда переводят весь сайт целиком на https. Если не EV, то лучше ограничиться только платежными формами, а информационным сайтам он вообще не нужен.
Чего-то выделывается китайский сервис, кириллические домены не принимает, даже отконвертированные в пиникоде… Да и латиницей тоже не все хавает. Из списка в 11 доменов, только на 1 не ругался… беда.
Я не был параноиком, пока все не сговорились.
Почему-то я ждал от гугл хотя бы дешевые сертификаты, после новостей Google повышает сайты с HTTPS в выдаче, Google Chrome пометит HTTP-сайты как небезопасные и т.д. Так скоро в выдаче на первых местах будут сайты с очень дорогими сертификатами, а потом дешевле, с бесплатными сертификатами сайты будут желтыми, а по http вообще не будет пускать (chrome) и показывать в выдаче поиска? Алло, Корпорация добра дома?
Так вы номером ошиблись.
Вот и начнется год китайских сертификатов в Рунете ))
Что у них с отзывом сертификатов? У StartSSL это платная услуга.
А может кто поделиться информацией, каким образом надо настроить OCSP stapling?
Нагуглил несколько статей, но они используются ссылки на сертификаты startssl, а для WoSign ссылочки другие будут же, верно?
Как советуют здесь (спасибо RicoX), URL можно вроде подсмотреть в «Данных сертификата» в свойстве «Доступ к сведениям центра сертификации».

По цепочке получил такие URL + StartSSL:

aia6.wosign.com/ca6.server1.free.cer
aia1.wosign.com/ca1g2-server1-free.cer
aia.startssl.com/certs/ca.crt
www.startssl.com/certs/sub.class1.server.ca.pem
www.startssl.com/certs/ca.pem

wget -O - https://www.startssl.com/certs/ca.pem | tee -a ca-certs.pem > /dev/null 
wget -O - https://www.startssl.com/certs/sub.class1.server.ca.pem | tee -a ca-certs.pem > /dev/null 
wget -O - http://aia.startssl.com/certs/ca.crt | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null 
wget -O - http://aia1.wosign.com/ca1g2-server1-free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null 
wget -O - http://aia6.wosign.com/ca6.server1.free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null 


И согласно рекомендации преобразовал их из DER в PEM формат. На выходе получил ca-certs.pem.

Конфигурация NGINX:
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/ca-certs.pem
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;


Проверяю, как рекомендуют тут:
openssl s_client -connect [site]:443 -tls1  -tlsextdebug  -status


0000 - 01                                                .
OCSP response: no response sent
depth=0 description = Free SSL Cert apply URL: https://buy.wosign.com/free, CN = aristsoft.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 description = Free SSL Cert apply URL: https://buy.wosign.com/free, CN = aristsoft.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 description = Free SSL Cert apply URL: https://buy.wosign.com/free, CN = aristsoft.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/description=Free SSL Cert apply URL: https://buy.wosign.com/free/CN=aristsoft.com
   i:/C=CN/O=WoSign CA Limited/CN=WoSign CA Free SSL Certificate G2
 1 s:/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---



Проверка на SSLLabs тоже показывает, что «OCSP stapling — No»

Буду признателен за добрый совет.

И можно ли что-то сделать с Mozilla (Ошибка: К сертификату нет доверия, так как отсутствует цепочка сертификатов издателя. (Код ошибки: sec_error_unknown_issuer)), или это своеобразная «плата» за «бесплатность»?
И можно ли что-то сделать с Mozilla (Ошибка: К сертификату нет доверия, так как отсутствует цепочка сертификатов издателя. (Код ошибки: sec_error_unknown_issuer)), или это своеобразная «плата» за «бесплатность»?

Видимо вы что-то не так настроили. У меня все работает во всех браузерах без проблем.
Да и кстати, WoSign отправляет цепочки доверия вместе с сертификатом. Также там есть уже подготовленные файлы цепочек для различных серверов, в т. ч. и nginx.

Сказать вам точно что делать не могу, так как настраивал на апаче, но OСSP Stappling на нем определенно работает.
Категорическое Вам спасибо.

Я действительно, взял из архива предподготовленный в поднебесной файл из папки «for Nginx».
После вашего комментария посмотрел его содержимое и оказалось что один из сертификатов был в DER, вместо PEM формата.

В папке «for Other Server» то же самое. Перевел его в PEM. И заново объединил.
Перезапустил Nginx и Mozilla перестал ругаться, а сайт получил A+ рейтинг вместо B.

Правда вот OСSP Stappling это не исправило. Но это уже пол беды.
удалось решить проблему с OCSP stapling?
Решить не удалось. Но, кажется, разобрался с причиной.
Сложилось впечатления, что WoSign не очень хочет поддерживать OCSP stapling или у них что-то сломалось.
Или у меня nginx чего-то не может. (v1.6.2)

Во всяком случае, nginx error.log полон таких вот записей:
2015/03/25 00:23:12 [error] 20691#0: OCSP responder sent invalid "Content-Type" header: "text/html" while requesting certificate status, responder: ocsp6.wosign.com
2015/03/25 07:36:03 [error] 21954#0: OCSP responder prematurely closed connection while requesting certificate status, responder: ocsp6.wosign.com



Ручная установка ssl_stapling_responder на разные нагугленные значения тоже не помогла.
аналогично. без результатов, такая же ошибка в логах
У меня в апаче все в порядке:
openssl s_client -connect [site]:443 -tls1  -tlsextdebug  -status

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = CN, O = WoSign CA Limited, CN = WoSign Free SSL OCSP Responder(G2)
    Produced At: Mar 25 10:41:04 2015 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: A06661F16CBCC23E98BC71914830B85AAA8D0A6B
      Issuer Key Hash: D2A716207CAFD9959EEB430A19F2E0B9740EA8C7
      Serial Number: 27EF81B5EA5699CECB7CF40275316340
    Cert Status: good
    This Update: Mar 25 10:41:04 2015 GMT
    Next Update: Mar 27 10:41:04 2015 GMT

Все настройки стандартные… Думаю проблема либо в настройках nginx либо в самом nignx.
Или как варинат, «великий китайский файервол» не хочет с вашим IP работать…
Возможно дата-центры Hetzner и вправду не по фен-шую стоят:)
Спасибо за ценный комментарий.
Буду разбираться. В таком случае, похоже, проблема действительно в конфигурации NGINX.
nginx, stapling, ocsp6.wosign.com.
Имела место та же проблема.

1. StartCom, корневой, затолкал в папку системных сертификатов, это который:

subject= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority notBefore=Sep 17 19:46:36 2006 GMT notAfter=Sep 17 19:46:36 2036 GMT SHA1 Fingerprint=3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F

2. пересобрал для nginx ssl_trusted_certificate файл trusted.pem из трёх (а в цепочке мне выдавалось четыре, где четвёртый — уже на свой домен) сертификатов, которые выдавал отладчик команды:

openssl s_client -connect [site]:443 -tls1 -tlsextdebug -status

На пока в логах нет этой ошибки.
Правильно ли понимаю, что у вас все работает нормально?
Если не сложно, можете расшарить trusted.pem файл?
только мне не нравится, что всё равно во всех попытках от www.ssllabs.com:
OCSP stapling: No

Блин. Надо разбираться вместе. :-).

Я туда склеивал:
ca1_dv_free_2.pem
ca1_xs_sc_2.pem
startcom.pem
перекопанное было оно тут: www.wosign.com/English/root.htm

trusted.pem
-----BEGIN CERTIFICATE-----
MIIFrDCCA5SgAwIBAgIQOPZFweJdkSzOOys5EjF0DTANBgkqhkiG9w0BAQsFADBV
MQswCQYDVQQGEwJDTjEaMBgGA1UEChMRV29TaWduIENBIExpbWl0ZWQxKjAoBgNV
BAMTIUNlcnRpZmljYXRpb24gQXV0aG9yaXR5IG9mIFdvU2lnbjAeFw0xNDExMDgw
MDU4NThaFw0yOTExMDgwMDU4NThaMFUxCzAJBgNVBAYTAkNOMRowGAYDVQQKExFX
b1NpZ24gQ0EgTGltaXRlZDEqMCgGA1UEAxMhV29TaWduIENBIEZyZWUgU1NMIENl
cnRpZmljYXRlIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA47SA
DmswUIIvH+edv/h8QiXtrmHE64aHI38RH8CTXxuSkB53jLx29/sKpdV9rNxLGNhY
Lt9GazQPRWRghMLrmg5R1CpUUT4nO2Rohm98awA8mfZMqEUnraXLKzftWcNSTE/e
NJzyt9H6WMvlYp5VRly3xY04JDXvlyx8ZRAN75+XCNXlsxJ6kt3+iA+PpK+9xdY2
90Eb6Fndhv81v+3k0aCTblGomcvf3b5xiMPasWXMe5XEZo++TgZ/m1OMazzOlyaC
Hxcwuj/I3swLobTvEj2Tywgw5xqYl4A6JoSP/nN0lVMPUbKqiVf0lkByEx3kZ5hO
j8ZAC/UdDEUt4NWSgwIDAQABo4IBdjCCAXIwDgYDVR0PAQH/BAQDAgEGMB0GA1Ud
JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATASBgNVHRMBAf8ECDAGAQH/AgEAMDAG
A1UdHwQpMCcwJaAjoCGGH2h0dHA6Ly9jcmxzMS53b3NpZ24uY29tL2NhMS5jcmww
cgYIKwYBBQUHAQEEZjBkMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcDEud29zaWdu
LmNvbS9jYTEwOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWExLndvc2lnbi5jb20vY2Ex
ZzItc2VydmVyMS1mcmVlLmNlcjAdBgNVHQ4EFgQU0qcWIHyv2ZWe60MKGfLguXQO
qMcwHwYDVR0jBBgwFoAU4WbPDtHxs0u3BiAU/ocS1fb++z4wRwYDVR0gBEAwPjA8
Bg0rBgEEAYKbUQYBAgIBMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly93d3cud29zaWdu
LmNvbS9wb2xpY3kvMA0GCSqGSIb3DQEBCwUAA4ICAQCWWt+WkRdokF0vtDIVgAMD
C+kct3Ns2qj6lN3dPjQrLoCTbPqmZ9MbeoJBzp7/P++yg2qe/DL9RPOCZqrPRC+z
N0HweRLjAieGSJK+z1bXy9fnHiWdQdsK5zMSWK2V2J7Ut5Upuv7/34Ckd1sVYg9p
+IdtdOqFonZdn5UuA7yK+YqsgWRQ8gtFS+yXMDl05ad+FiRiK1DxXNhPzS6iGCWj
zvYfYN0V3iAVGw5/r4XZQKwHKjTdUbAaqOYOn1/bRnDm9dklHPAd5UKhLSKdbhHJ
jaZlvA6qdnPIVmAv+z+GuaX1M+/VEx9JTDgHnlkiWsdO2SUkulNw/GMqVFHrw0tB
feToPCyldlq/2UyoDa5SbqVdmD1skG14H8NwlYYHP1Tj6oqBZGKajzGveyp+kiLD
jsxTrMecmRErSD9ScStuwOGzCuUDYteJGChMCo0/C0WJgYuIpJPCf0TlHltAAPwv
zDv4ankx/UQUto9IhUyrCp27Nwr8URng/llqO49gYqcHgq8IZqDy2mAC6tg0fldx
obX+adf73Vqc8//E6s10+pRw01iSzq8S5G7r3bivHeJl1EbqCz7jaA4KTCeDUJEG
xnv4+psm7SwOZ7hs5SyYbV96KMOEPAMN9+ID4ZTCWCf4TYFZL/F8YclXXb3cnIDQ
ZN98h3iF5pSLcIsFR+TIew==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGXDCCBESgAwIBAgIHGcKFMOk7NjANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQG
EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MjI0NjM2WhcNMTkxMjMxMjM1
OTU5WjBVMQswCQYDVQQGEwJDTjEaMBgGA1UEChMRV29TaWduIENBIExpbWl0ZWQx
KjAoBgNVBAMTIUNlcnRpZmljYXRpb24gQXV0aG9yaXR5IG9mIFdvU2lnbjCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL3Kjay4kRVWl3trXHrC3mvZobDD
ECP6p6GyzDH6PtmmKW8WPeBr+LhAX9s5qAB6i6BNVH3CInj8jgm4qIXXzJWXS3TY
nn7wAOQOia5JKEQaEJkyDyWIU6QNsw8SCBYLA3EnHH/h29L9Z2jEBV0KDl1w19iX
oLxTQZqRjfSeNmZ6flbBkF/msWggNqSMJCwsRwtZdmYwtb7e7Y/4ndO7ATDm8vMO
4CySgPOF+SiKtFQumu33dvwVaBbrSmzrLhKP1M/+DMdcHQt+BTK+XrAJKkLVyU6Q
s1kNu3p+zdUIWrR/2BxpEfknD3sGr1SDGHvh3VR6UWhud/zGv1JKZkahsmcau6NP
d6C+Xf/8VgtDcneQyp758jn1Dan06tfnsxAvMEI3IcwwcMmGmA/MWE2Du33lGqU3
jbasMpcAOmNxJB6eN8T/dNQ3wOL+iEZgEd0IP1A2q7h6pJViam6wymohWmnz8/sd
cDmV86dupoGJoYjFO3HKo1Lug7v9oHf05G/nQtttSpmKNEi8F9zkgAgitvIxwD8E
PuufIHnWuAZkZAIx16nNUvuERWkJACrcVYvEBkZLwEodCVs5KP2pq84A+S5ISybm
MEylWMq0RIJP55EeM8Owk/8R/IHSyh9xKd12T5Ilrx2Btw8vjMMGzC8no0rkDpm6
fB5FH3+qGUWW/fw9AgMBAAGjggEHMIIBAzASBgNVHRMBAf8ECDAGAQH/AgECMA4G
A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU4WbPDtHxs0u3BiAU/ocS1fb++z4wHwYD
VR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwaQYIKwYBBQUHAQEEXTBbMCcG
CCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwMAYIKwYBBQUH
MAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAyBgNVHR8E
KzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwDQYJ
KoZIhvcNAQELBQADggIBALZt+HD74g1MmLMHSRX1BMRsysr1aKAI/hJtnAQGya2a
kVI+eMRc7p9UHe7j8V4wyUnhOeCmnTZsV/rmNE9V6IeoLN0F8VgSkejKzih4j98H
hQGl3EWWBdSAsisFmsuapYvgOmfmc0e+Sv0nsYjv5srPjQ4mn/pfV3itbf6umzUI
scO6wQBKS30Uvffx01UYrNAzcIhtxAlxFKYrT4iB5wsAN6kVfX7XAZY/L697Yq4K
Sr9LOS41EIv+BDnkPDoMCVZAOrX0wmgMtflSze6d+Jj8eOdYR48cc1hpM6v/3d+O
JAF3mBk6sGZ5vOEIow5PwQSz8wHI69NZHDXSkx5wZYJ/28/7yJkSYMNEbzqAS9e+
IaoUemTL3TdDRVsyLkXw2VkfaxjwfOlVNhlhX7V98Y29iOR1S5jdJ7DkhEQqYYRX
BYIRH6o1WPMgDq9Z7/pVcnINJtCbU0mszjcuZWH/9uwb6vbxptPRtXu+NfQiwbyN
Ab1oXoMNL+zW2mMMJ9FUPuSo085LMriRlP/7W0ktdRiounGaO67ZwKlPh5Hti3tr
IJiJOYNPgMRpzBfJyE6+5KmlgXZwBgQyzYNl9Lx9PhO80uhvY6q1O9qNhjKCeJ3Z
zP+/V2R07Sg9RGIVYUv3lLANKmcc8MubpZK/+EFawT1g7Z+7uG2bzqlqFj9+6gbx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk
pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf
OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C
Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT
Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi
HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM
Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w
+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+
Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B
26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID
AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE
FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js
LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM
BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy
dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh
cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh
YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg
dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp
bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ
YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT
TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ
9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8
jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW
FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz
ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L
EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu
L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq
yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC
O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V
um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh
NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14=
-----END CERTIFICATE-----
При этом тестирование:

echo QUIT | openssl s_client -connect %YOUR_STAPLED_SITE%:443 -status 2> /dev/null | less'

вполне мирно отвечает:

CONNECTED(00000003)
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = CN, O = WoSign CA Limited, CN = WoSign Free SSL OCSP Responder(G2)
    Produced At: Mar 25 16:21:03 2015 GMT

Попробывал подсунуть ваш файл trusted.pem
Ничего не изменилось ни в поведении команды:
openssl s_client -connect [site]:443 -tls1 -tlsextdebug -status

ни в error.log:
2015/03/25 23:22:14 [error] 4126#0: OCSP responder prematurely closed connection while requesting certificate status, responder: ocsp6.wosign.com


Похоже как хост ocsp6.wosign.com брыкается.
Попробуйте подключится telnet-ом со своего хоста к 80 порту ocsp6.wosign.com
(судя по сертификату он именно на 80 должен отвечать)
telnet на 80 порт соединяется без проблем
Значит «великий китайский файрволл» не причем…
Не знаю чем помочь больше…
Разве что включить трейсы в логах или на худой конец проснифить трафик.
Видимо ocsp6.wosign.com выдает какую-то ошибку, надо бы посмотреть что ему отправлялось и что он ответил.
Да, согласен, скорей всего дело в некорректных настройках.
Спасибо за помощь.
есть идеи куда копать?
nginx.org/ru/docs/ngx_core_module.html#error_log попробуйте посмотреть что будет в логах если включить уровень notice, а лучше debug (правда с ним могут быть проблемы, судя по всему).
Пока только как посоветовал TriAn
И еще есть подозрение, что нужно правильную цепочку («For ssl_stapling_verify to work, this file must contain the Root CA cert and the Intermediate CA certificates») сертификатов в правильном порядке подобрать для ssl_trusted_certificate

Вот эта команда выполняется нормально:
openssl ocsp -noverify -no_nonce -respout ocsp.resp -issuer [~/tmp/issuer.pem] -cert [~/tmp/server.crt] -url http://ocsp6.wosign.com/ca6/server1/free


По идее файл ocsp.resp можно скормить директиве ssl_stapling_file
мне тут подсказали, что нужно передавать заголовок с хостом, т.е сервер понимает только HTTP 1.1, что-типо такого:

openssl ocsp -issuer chain.pem -cert site.ru.pem -text -url http://ocsp6.wosign.com/ca6/server1/free -header "HOST" "ocsp6.wosign.com"


попробуйте, сам я не очень силен в этом…
В общем, я попробовал сдампить успешную транзакцию к OSCP серверу со своего апача.

Судя по тому, что где-то у вас nginx ругался на неверный «Content-Type» ответа OSCP сервера, в этом ответе был текст ошибки. Попробуйте выполнить
ngrep -q -W byline host ocsp6.wosign.com

и посмотреть что в нем.

Если ответ правильный, то должно быть
что-то типа этого
interface: enp0s3 (10.0.2.0/255.255.255.0)
filter: ( host ocsp6.wosign.com ) and (ip or ip6)

[.....]

T 10.0.2.15:56353 -> 106.120.160.249:80 [AP]
POST /ca6/server1/free HTTP/1.0.
Host: ocsp6.wosign.com:80.
Content-Type: application/ocsp-request.
Content-Length: 83.

[запрос]

[.....]

T 106.120.160.249:80 -> 10.0.2.15:56353 [AP]
HTTP/1.0 200 OK.
Content-Type: application/ocsp-response.
Content-Transfer-Encoding: Binary.


T 106.120.160.249:80 -> 10.0.2.15:56353 [AP]
Content-Length: 1514.
Date: Mar 26 08:47:49 2015 GMT.
Expires: Mar 28 08:47:49 2015 GMT.
Connection: close.

[в тексте, в первых нескольких строчках]
WoSign Free SSL OCSP Responder(G2)
[тоже почти в начале, интервал валидности ответа (2-е суток)]
20150326084749Z....20150328084749Z
[.....]


у меня с другого сервера, на другом континенте при том же конфиге — сыпятся эти ошибки.

Удалось достать контент из html-ответов с ocsp6.wosign.com?
Может они там через раз отвечают чем-то типа «503 Try again later… и далее»?
+ коннективити нестабильное в их Чинанет.

Возможно этот шестой сервак отвечает по остаточному принципу, и часть запросов таймаутятся и дропаются, «получите, задармшное», а часть просто роутятся на (бгг) страничку с рекламой :-), мало ли.
Разобрались?

Я переставил FreeBSD (а там был dev-nginx) на убунту LTS, ну а там древний nginx (1.4), перестало работать.

Заапдейтил nginx

add-apt-repository ppa:nginx/development
apt-get update
apt-get remove nginx
apt-get install nginx

и заработало. Причём не на локальных тестах, а на ssllabs.com:
OCSP stapling Yes

У меня поставился: nginx (1.7.11-1+trusty0). Можно, если что, ppa:nginx/stable — может и 1.6 сработает, но я на свой сервер смелее решил быть :-).
Если стоят модули типа Nginx Perl — то надо remove nginx-* + install nginx-extras

И да, последовательность объединения сертификатов, и прочая — я вообще свалил в .pem-файл все, что насобриались тут вокруг Starcom/WoSign

1_ca.pem                   2760 bytes
2_sub.class1.server.ca.pem 2090 bytes
4_ca1g2-server1-free.pem   1956 bytes
5_ca6.server1.free.pem     2029 bytes
6_ca1_xs_sc_2.pem          2264 bytes
7_ca1_dv_free_2.pem        2029 bytes
8_WS_CA1_G2.pem            1269 bytes
9_WS_CA1_NEW.pem           1956 bytes


То-то я бился, что у меня с одного сервера месяц назад не работало (убунта) а с моего под боком (фря) работало.
Да, решение тут.
На 1.6.2 с конфиг-костылем заработало, потом обновился до 1.7.11 и без костыля тоже все норм.
Я разобрался c помощью ссылки от Pulse, что nginx отправляет запрос не так как его ждут в поднебесной. nginx кодирует параметр GET запроса на ocsp сервер, коим является base64 строка и если там попадается символ =, то он превращается в %3d и они перестают друг-друга понимать. По всей видимости, тут многое зависит от случая, какой достанется сертификат и появится ли в GET запросе символ =, что объясняет почему у кого-то все без проблем работает, а у кого-то сложности.

Обновление до 1.7.11 на ubuntu 14.04 не дало никакого результата.
Пока оставил все как есть.
Думаю, имеет смысл как-то оповестить об этом Wosign. Но что-то я не нашел для этого подходящего способа, кроме как написать письмо на ящик help@wosign.com но за два дня ответа так и не получил.
Спасибо!
Как же вовремя этот пост :-)

Последнюю недельку в качестве сайд-проекта пишу PoC для HSTS Super Cookie, которая работала бы при включенном NoScript, и для этой балалайки нужно иметь сертификат на ~32 поддомена. При чем самоподписанный для этого не годится, а выкидывать сотню с лишним баксов только «ради искусства» казалось нерациональным. Я уже было похоронил идею делать живую демку, ограничившись исходниками на гитхабе, и тут такой подарок судьбы. Шикарно.
Ждем статью с результатами!
Будет. Когда таки закончу :-)
Wildcard нельзя, что ли? Конечно, были разговоры о форсировании includeSubDomains для wildcard-сертификатов с целью предотвращения HSTS tracking, но, к счастью, до этого не дошло.

www.leviathansecurity.com/blog/the-double-edged-sword-of-hsts-persistence-and-privacy/
www.ietf.org/mail-archive/web/websec/current/msg00978.html
Wildcard сертификат можно, конечно, но стоит он недетских денег. Что касается общего резюме, то опасность такого вида трекинга сильно преувеличена, а PoC я пилю исключительно ради искусства :-)

На данный момент я знаю, что Chrome и Firefox планировали сбрасывать HSTS кэш при очистке кукисов, так ли это — я не проверял. Зато знаю, что Firefox при заходе в приватный режим стартует с пустым кэшем HSTS, а у Chrome он общий в обоих режимах. Соответственно, за пользователем хрома таким способом можно следить даже если он попытается зайти в приват, но с точки зрения общих рисков такое решение кажется более правильным (угроза безопасности кажется более серьезной, чем гипотетическая слежка).
В Chrome если на HSTS-сайт всегда заходить только в приватном режиме, HSTS только в рамках сессии, а так не запоминается.
Занятно, такой сценарий я не проверял. Спасибо :-)
А можно это сделать без использования почты webmaster@mydomain.com? Хочу сертификат на свой сервер, почты на нем нет, ставить ради одного письма лень.
habrahabr.ru/post/249529/#comment_8260181 — тут же на 9 шаге как раз без подтверждения через почту делается. Файл в корне сайта.
Что-то я грешным делом подумал что 100 доменов — это wildcard certificate, но похоже нет.

Интересно, а что произойдёт, если я захочу выписать новый сертификат, в котором уже явно перечислены нужные мне домены?
Видимо хабраэффект настиг и Китай, а то у меня как-то с перебоями заходит.
китайские сайты сами по себе у нас не шустро открываются — маршрут далекий.
Если создавать запрос на сертификат так:
openssl req -out mydomain.com.csr -new -sha256 -newkey rsa:2048 -nodes -keyout mydomain.com.key
или даже так
openssl req -out mydomain.com.csr -new -sha512 -newkey rsa:4096 -nodes -keyout mydomain.com.key
то на шаге ввода запросы на китайском сайте показывает, что Signature Algorithm: sha1
И после выдачи сертификата, в нем стоит sha1, как сделать чтобы было sha2?
Вы решили свою проблему?
Получил сертификат — а в итоге SHA1.
При заказе сертификата указал SHA2. Ключ генерировал сам.
Нет, не путаю
А его все браузеры корректно поддерживают? А то у меня были проблемы с сертификатом StartSSL на мазиле.
И еще вопрос. У меня некоторые библиотеки тянутся не с моего сервера (например шрифты), а с других http ресурсов, как это отразится на моем сайте, не будет ли у меня висеть предупреждение возле адреса ресурса?
Необходимо, чтобы все ресурсы качались либо по такому же протоколу что и сайт (типа <img src="//cdn.example.com/image.png">) либо же всегда по HTTPS. Браузеры сейчас в принципе не грузят mixed content (тупо блокируют запрос).
Пассивный mixed content (мультимедиа, как в вашем примере) по умолчанию НЕ блокируется. Причём в Chrome и Firefox есть уязвимость, когда даже при вручную заблокированном пассивном mixed content он может быть загружен. Например, прописывание HTTPS-ссылки, которая на самом деле осуществляет 301 редирект на HTTP-ресурс.
А я вот на днях борол проблему — на новом сайте (на новом сервере) картинки не грузились со старого сервера по HTTP и хром ругался в консоли, что загрузка смешанного содержимого была заблокирована, пришлось настроить https на старом сервере. Умолчания могли и поменять.
Необходимо отсылать с сервера вместе с самим сертификатом и все промежуточные: настроить веб-сервер и потом проверить SSL Test'ом. Для StartSSL инструкция тут: www.startssl.com/?app=42
Кстати, тут китайцы молодцы — сразу bundle из всех нужных сертификатов присылают.
Когда в России кто-то из компаний первой решится сделать то же? Т.е. я понимаю, что продавать сертификаты — это еще выгоднее даже, чем СМС по 2...5 рублей пересылать, но имиджа ради можно, наверное, самые простые сертификаты выдавать не на «тестовый» месяц, а на год, а то и два?

Reg.ru правда объявил было, что при аренде у них сервера или VPS (от какой-то цены, конечно — думали, к минимальным будут такие «подарки»?) клиенту бесплатно делается сертификат, но там речь не идет про 200 имен, да и условия точно не прописаны (хотя ТП говорит о «сертификате на время действия договора») — но китайцы еще большие молодцы, что нанесли удар по индустрии продажи за деньги некой слепой веры в безопасность.
Похоже, не хотят китайцы заказ с русского IP обработать :) Несколько часов тишины!
Утром (по китайскому времени) будет сертификат, они где-то об этом пишут.
Где-то в 7 по Пекину пришло, да.
Теперь бьюсь с nginx и OCSP — sec_error_ocsp_unknown_cert.
Из присланногоо бандла в файл для директивы ssl_certificate пихаете все сертификаты кроме последнего (корневого), а в файл для директивы ssl_trusted_certificate — все, кроме первого (сертификата сайта). Я так сделал и nginx завёлся. Но SSL Test всё равно считает, что OCSP Stapling'а у меня нет. И хром зелёный замок не кажет. Если у вас получится — расскажите, как оно настроить.
Firefox отвергает подобные телодвижения.
Ошибка все та же: sec_error_ocsp_unknown_cert

Хром(иум) — работает, этого пока что хватит.
Для OCSP Stapling нужны ВСЕ сертификаты.

Если всё равно не заработает, попробуйте в обратном порядке, от корня до сайта, я для ssl_trusted_certificate всегда только так делаю.
Получил вчера сертификат, примерно через час после прохождения квеста ;) Спасибо за пост!
Настроил этот сертификат на страничке имени себя: отчёт SSLTest.

Из проблем: из присланного bundle надо выкидывать последний (корневой) сертификат. На один из сертификатов в цепочке (причём какой-то лишний) SSL Test ругается, ещё говорит, что нет OCSP Stapling'а (сделал аналогично StartSSL'ю, но что-то не завелось), хром тоже говорит про «устаревшие параметры безопасности» и не показывает зелёный замок.

Вывод: вернусь-ка я лучше к сертификату от Start SSL.
---> хром тоже говорит про «устаревшие параметры безопасности» и не показывает зелёный замок.

Это потому что в цепочке доверия WoSign корневой сертификат — StartSSL. Внезапно, да? WoSign — это только промежуточная цепочка, а «устаревшие параметры безопасности» из-за того, что этот промежуточный сертификат с алгоритмом подписи SHA1.
Chromium 41 показывает зеленый замок. Взял новый сертификат, на этот раз sha2 + .key генерировали китайцы.
---> причём какой-то лишний

Приехали, называется. Этот «лишний» сертификат нужен для того, чтобы ваш сайт был доверенным для Internet Explorer и Google Chrome. Просто они догружают этот сертификат самостоятельно, раз уж вы не соизволили необходимый сертификат в цепочку добавить.

Никогда не слышали о механизме cross-signing? Когда сертификат одного CA, которому ещё мало кто доверяет, выдаётся от имени уже более доверенного CA? Только Mozilla доверяет WoSign как самостоятельному CA.

Перепись таких же счастливчиков: www.lowendtalk.com/discussion/41289/free-chinese-2-year-ssl-certificate-dv-kuaissl-by-wosign-com

Стыд — habrastorage.org/files/012/bb0/e57/012bb0e5753a4fa3b60c2c4283f8f4da.png

Вопрос, конечно, к автору, зачем он эту статью написал. Мне теперь всё это говно разгребать!
Про кросс-подпись не слышал, но по наличию разных цепочек в выводе SSL-теста о ней догадывался. Вы бы лучше не ругались, а скинули полезных ссылок на просветиться.

Этот сертификат из бандла я выкинул сознательно, потому что в выводе SSL Test'а он указан, как «In trust store», а информации про то, какой браузер кому доверяет, а кому — нет, там нет.

P.S> А почему всё это говно разгребать именно вам?
Просто понимаете, за всё это время автора в комментариях ни разу не было, а буквально неделю назад в сообществе SSL Labs уже была тема про WoSign, которую я помог разрулить, её автор в итоге обратно на StartSSL перешёл.

На эмоциях просто.
---> Этот сертификат из бандла я выкинул сознательно, потому что в выводе SSL Test'а он указан, как «In trust store»

Ругается на другой сертификат, хотя у него такое же название.

Вот нужный сертификат: pastebin.com/rzzT3d5i
1. Корневому сертификату WoSign доверяет только Mozilla, но не Microsoft.
2. Из этого следует вопрос: как в Internet Explorer и Google Chrome открываются сайты с сертификатом от WoSign? Один раз в статье и 11 раз в комментариях упоминали StartSSL. Да, Microsoft доверяет WoSign благодаря StartSSL, который подписал сертификат WoSign от своего имени.
3. Подпись промежуточного сертификата WoSign сформирована по алгоритму SHA1. Промежуточного… SHA1… Вы понимаете, что это означает для Google Chrome, самого популярного в мире браузера?

ИДЕНТИФИКАЦИОННЫЕ ДАННЫЕ НЕ ПОДТВЕРЖДЕНЫ
На этом сайте используются устаревшие параметры безопасности. Возможно, после обновления Chrome нельзя будет открывать его через защищённое соединение.

Автор, это просто издевательство!
У меня наоборот Mozilla не доверяет этому сертификату. Но зачем же вы обвиняете автора?
Хотите нормальный сертификат, покупайте с EV. Просто есть сценарии, при которых практически невозможно обойтись без «доверенного» сертификата, а покупать его не очень хочется, потому что «вдруг не взлетит». Например, в моем случае очень даже помогло:
social.technet.microsoft.com/Forums/ru-RU/2eca3f89-cca5-4734-bef9-428a8f5fb594/onedrive-for-business-sync-nonad?forum=sharepointadmin
EV только организациям выдают, да и с ним тоже можно налажать, как Альфа-банк: habrastorage.org/files/dbe/c77/0aa/dbec770aa0fa4389a2a45fd2d8bd692c.png

Ирония в том, что они объявили о прекращении поддержки браузеров, которые не умеют SHA2, а в итоге снова получили сертификат SHA1.
Ситуация с пошаговой инструкцией несколько изменилась.
Теперь после проверки электронной почты надо зайти на страничку buy.wosign.com/free/freessl.html?lan=en и уже на ней подтверждать владение доменом и вводить свой CSR
Также обещают отличия в цепочках доверия платных и бесплатных сертификатов: screencast.com/t/Zrsp0EOF6f
Ну да, для сертификатов с разными уровнями проверок разные промежуточные серверы, практически у всех так :).
Борюсь с настройкой OSCP Stapling, но получаю ошибку:
OCSP ERROR: Exception: Read timed out [http://ocsp6.wosign.com/ca6/server1/free]

Это только у меня в следствии кривых настроек или проблема массовая?
то же самое.
Возможно, что проблема не массовая. Но вы не точно одиноки.
OCSP stapling Yes
Оценка A+
Ура! Описал свои действия у себя в блоге
чем ваши настройки отличаются от этих?
habrahabr.ru/post/249529/?reply_to=8349221#comment_8339685

один-в-один.

но в моем случае, как и у автора коммента — не работает OCSP
Отличаются тем, что в конфете домена в разделе server указаны строки
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH';
 add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

Про это там не сказано, и у автора комментария не сработало.
у меня указано, но тоже не работает:

OCSP response: no response sent
Прежде чем писать сюда, я проверил это на всех своих доменах (blog.kai-zer.ru,kai-zer.ru,rss.kai-zer.ru), и везде результат положительный.
а версия nginx какая?
у меня 1.6.2

так-то тоже рейтинг А+ показывает.

мб действительно лажа с сетью, а вот у вас с DO работает нормально
Проверено на 1.6.2 и на 1.7.11
(Последний стабильный и mainline релизы).
Вопрос к пользователям сертификатов WoSign.

Мне тут пришли вчера письма со ссылками на загрузку всех моих сертификатов; как будто я их перезаказал или что-то в этом духе.
Никто не в курсе с чем это может быть связано?
P.S.: Файлы сертификатов, по крайней мере для Апача не отличаются ничем от ранее скачанных.
Да, вчера тоже поймал несколько писем ранее заказанных и полученных сертиков.
Какой-то сбой в почтовом сервере у них — были отправлены письма повторно.
Да, точно, ссылки в письмах идентичные.
Мне так же пришло, письма копии прошлых, видимо действительно сбой.
Здравствуйте!
Кто-нибудь пользовался индивидуальным сертификатом, который WoSign выдал при регистрации?
У меня никак не получается его использовать.
Возникла необходимость сделать новый сертификат, удалив предыдущий, а удаление не позволяет сделать при авторизации через логин-пароль (типа недостаточно безопасно).

Или кто-нибудь пользовался переиздачей сертификата — там происходит запрос нового запроса на сертификат (request)?
Спасибо!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории