S/MIME в Microsoft

Продолжая криптографическую тему хочется отметить некорректности вот этой статьи (Outlook S/MIME certificate selection):
http://blogs.technet.com/b/pki/archive/2008/12/17/outlook-s-mime-certificate-selection.aspx

Достаточно много народа на нее ссылались, поэтому тема ее неточностей - актуальна.

"When sending an encrypted eMail, Outlook actually requires two certificates. One certificate is owned by the recipient and one is owned by the sender. The recipient’s certificate is used by the sender for encrypting the eMail which is sent out. The sender’s certificate is used by the sender to encrypt the eMail that is stored in the Sent Items folder in Outlook"

Из абзаца может показаться, то письмо шифруется дважды: на ключе отправителя и кладется в Отправленные, и на ключе получателя - и отправляется.

На самом деле это не так: письмо шифруется один раз на ключах всех получателей и на ключе отправителя. Цитата из RFC3851, раздел 3.3:

"Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6)."

Из сего факта есть интересно следствие, что, будучи получателем письма, я могу залезть в ящик к отправителю и прочитать отправленное мне письмо своим ключом. Это может повторить любой из получателей, причем, применительно и к отправителю и к любому из получателей.

Далее,
"To find a valid certificate owned by the recipient, Outlook verifies if any certificates are stored in the userSMimeCertificate attribute in Active Directory. If so, Outlook examines the PKCS#7 blobs to find out if Outlook is the one that published them. In that case, there is an extra signed attribute that indicates which is the default certificate. If the certificate marked as default is found in the userSMimeCertificate attribute, it is chosen. If the default certificate is not found, the first valid certificate in the store is selected. In case the userSMimeCertificate attribute stores no certificates, Outlook queries the userCertificate attribute in Active Directory"

Может сложиться впечатление, то Outlook берет сертификат непосредственно из AD, и, увидев сертификат в AD, можно долго удивляться почему же Outlook его никак не находит при попытке написать письмо.

На самом деле все не так. Может пройти аж до 48 часов с момента выпуска пользователю сертификата до момента появления возможности отправки ему шифрованного письма.

Очень понятно и подробно об этом написано в KB#841273 - Administering the offline address book in Outlook. Очень рекомендую это внимательно почитать. В двух словах - сертификат берется не из АД, а из локальной копии автономной адресной книги, которая на сервере Exchange генерится не часто (по умолчанию - раз в день), и также нечасто забирается Outlook-ом для автономной работы (если включено кеширование, которое включено по умолчанию).

Еще важно отметить, что по умолчанию Outlook всегда хочет проверять CRL как для сертификатов получателей, так и для сертификата отправителя. Тут может быть масса проблем, начиная с недоступности указанных в сертификате CDP, заканчивая банальными настройками прокси, когда локальный CRL не скачивается по HTTP через настроенный прокси. Не хочу говорить, что я бы рекомендовал отключение проверки CDP, но думать об этом надо.

Вообще, полезно почитать перечень криптопараметров Outlook и решить что как подкрутить в соответствии с потребностями (Plan for e-mail messaging cryptography in Outlook 2010):
http://technet.microsoft.com/en-us/library/cc179061.aspx

Свой собственный УЦ на OpenSSL

Снова пришлось упражняться с криптографией в исследовательских целях: надо было поднять свой (недоверенный в домене УЦ и проверить с ним некоторые штуки). Необходима была цепочка УЦ, т.е. что-то типа: Корневой УЦ --> Еще УЦ --> уже мой сертификат:


Инструмент - OpenSSL.
Пост пишу, главным образом для себя, чтобы в следующий раз не тратить время, а просто сделать по описанному порядку.

После того, как OpenSSL скачали и поставили.
1. Делаем корневой УЦ.
1.1. Делаем для него папку и подпапки:
Текстовый файл не содержит ничего (комментарий).
serial - содержит текущий сериальный номер сертификата.
serial.old - будет сделан после выпуска сертификата - там запишется предыдущий.
index.txt - надо сделать пустым. Все остальные index.txt.* сделаются после выпуска сертификата с этого УЦ.
openssl.cnf - копия дефолтного с незначительными изменениями, применительно к данному CA. Файл снабжен понятными комментариями.

1.2. Выпускаем корневой, самоподписанный сертификат:
openssl req -new -x509 -days 3650 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -config openssl.cnf

При этом секретный ключ будет положен  cakey.pem, сертификат - в cacert.pem.

2. Делаем выпускающий УЦ, подчиненный нашему корневому.
2.1. Такую же структуру папок:

В папку clients будем складывать сертификаты и pfx-ы клиентов (вручную, само туда класться не будет - чтобы корневая папку УЦ не засорялась).



2.2. Делаем запрос на сертификат выпускающего УЦ (почему-то я его назвал Subordinate): 
openssl req -new -days 3650 -keyout private/subcakey.pem -out subcareq.pem -config openssl.cnf


2.3. Идем на наш Корневой УЦ (== просто делаем туда CD) и выпускаем сертификат на только что сделанный запрос (подписываем запрос):
openssl ca -in ..\subca\subcareq.pem -extensions v3_ca -config openssl.cnf

3. Выпускаем сертификат для пользователя.
3.1. Идем на наш подчиненный УЦ (выпускающий УЦ) и делаем там запрос для пользовательского сертификата:
openssl req -new -days 365 -keyout key.pem -out req.pem

3.2. Подписываем запрос ключем УЦ:
openssl ca -in clients\req.pem -out clients\cer.cer -config openssl.cnf

3.3. Делаем из PKCS#12 (сшиваем ключ и сертификат в PFX):
openssl pkcs12 -export -out cer.pfx -inkey key.pem -in cer.cer

3.3* Иногда бывает нужно вытащить из PFX только секретный ключ, иногда хочется его вытащить и сохранить без шифрования, - команда ниже:
openssl pkcs12 -in ppp.pfx -out ppp.pem -nodes

Ключ будет сохранен в ppp.pem.

Ошибки.
1. Иногда, когда много раз упражняемся с выпуском сертификатов для одного пользователя, возможно возникновение ошибки при вызове команды п. 3.2
.....
Sign the certificate? [y/n]:y
failed to update database
TXT_DB error number 2
Здесь проблема связана с тем, что в одном CA OpenSSL не может быть более одного сертификата с одинаковыми параметрами. Для решения необходимо отозвать старый сертификат этого пользователя и повторить команду. Отозвать можно так:
openssl ca -revoke clients\certfilename.cer -config openssl.cnf

2. Для организации S/MIME в Outlook сертификат должен иметь определенные keyUsage и extendedKeyUsage:















Для указания этого OpenSSL проще отредактировать openssl.cnf:
[ usr_cert ]
....
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = critical, emailProtection
....

Анонимусы лучшие

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

Финальная фаза на которую нет смысла тратить время тут
Анализ фазы 1 тут и тут.

PS. леечка предлагает поделиться расшифрованными хешами со страждущими. Ради этого стоит записаться в твиттер.