Нет MIME-сертификата для подписи от имени летучей мыши

Обновлено: 06.07.2024

В этом введении представлена общая информация и контекст с целью облегчить толкование настоящей Хартии.

Сертификат S/MIME содержит открытый ключ, привязанный к адресу электронной почты; а также может содержать информацию о физическом или юридическом лице, которое контролирует такой адрес электронной почты. Затем пару ключей можно использовать для подписи, проверки, шифрования и расшифровки электронной почты. Сертификат S/MIME можно идентифицировать по наличию идентификатора объекта (OID) расширенного использования ключа (EKU) 1.3.6.1.5.5.7.3.4 для emailProtection.

Целью сертификата S/MIME является предоставление услуг криптографической безопасности для приложений для обмена электронными сообщениями, а именно аутентификация отправителя, целостность сообщения и конфиденциальность сообщения посредством шифрования. Для эффективной аутентификации и конфиденциальности обязательно, чтобы центр сертификации проверял личность субъекта (если он присутствует) и его адрес электронной почты. Получатель сообщения с цифровой подписью может аутентифицировать сообщение электронной почты, чтобы получить защиту от спуфинга электронной почты, и может зашифровать ответ исходному отправителю, обратившись к открытому ключу, адресу электронной почты и отличительному имени (если имеется), содержащимся в S/MIME. сертификат.

Основным вариантом использования, рассматриваемым рабочей группой, является модель, согласно которой отправители и получатели сообщений электронной почты получают «разумную уверенность» в том, что другая сторона сообщения, указанная в сертификате, имеет контроль над доменом или адресом электронной почты. Разновидностью этого основного варианта использования является ситуация, когда физическое или юридическое лицо подписывает электронную почту цифровой подписью, чтобы установить ее подлинность и источник происхождения.

Поэтому, чтобы обеспечить разумную уверенность, крайне важно установить стандартный метод проверки адреса электронной почты и личности субъекта (если он есть) перед их привязкой к открытому ключу. «Разумная уверенность» должна быть определена и определена этой SMCWG путем изучения существующих методов, существующих в отрасли, а также рамок управления идентификацией и любого применимого законодательства.

Сертификат S/MIME также можно использовать в автоматизированном сообщении с агентами передачи, которые используют службы криптографической защиты, не требующие вмешательства человека, например, для подписи документов, созданных программным обеспечением, и для шифрования факсимильных сообщений, отправляемых по сети. Интернет. Хотя эти существующие варианты использования не входят в сферу компетенции SMCWG, SMCWG будет проявлять осторожность, чтобы избежать непреднамеренных неблагоприятных последствий для этих видов использования. Безопасность, стабильность и отказоустойчивость Интернета должны учитываться при формировании консенсуса SMCWG. SMCWG будет консультироваться с другими техническими сообществами, когда это необходимо.

Проблема, которую должна решить рабочая группа, заключается в отсутствии последовательных и проверенных методов проверки, используемых центрами сертификации для установления личности субъекта (если он присутствует) и проверки того, что подписчик контролирует адрес электронной почты. Несмотря на то, что существуют методы проверки контроля над доменом, которые можно использовать с сертификатами TLS, в настоящее время не существует стандартных требований для проверки контроля над адресами электронной почты. Также существуют методы проверки удостоверений в сертификатах TLS, которые следует использовать там, где это возможно, а также другие стандарты проверки удостоверений, распространенные в отрасли. SMCWG также должен рассмотреть по крайней мере один метод эффективной проверки адреса электронной почты, а также разработку согласованного профиля для сертификатов S/MIME для облегчения технической совместимости в Интернете.

Целью SMCWG является предоставление документов, описывающих интегрированный набор технологий, протоколов, проверки подлинности, управления жизненным циклом и требований к аудиту, которые необходимы (но недостаточны) для выпуска и управления общедоступными доверенными сертификатами безопасности. /MIME-сертификаты; Сертификаты, которым доверяют в силу того факта, что соответствующий им корневой сертификат распространяется в широкодоступном прикладном программном обеспечении. Такие требования не являются обязательными для Удостоверяющих центров до тех пор, пока они не будут приняты и введены в действие проверяющими поставщиками прикладного программного обеспечения.

Учреждение рабочей группы по сертификатам S/MIME

Уполномоченная рабочая группа («SMCWG») создается для выполнения действий, указанных в настоящем Уставе, в соответствии с положениями и условиями Устава CA/Browser Forum и Политики прав интеллектуальной собственности (IPR), поскольку такие документы могут меняйте время от времени. Этот устав рабочей группы по сертификатам S/MIME был создан в соответствии с Постановлением CAB Forum 5.3.1. В случае противоречия между настоящим Уставом и любым положением Устава или Политики ПИС, положение Устава или Политики ПИС ДОЛЖНО иметь преимущественную силу. Определения, содержащиеся в Уставе Форума, ДОЛЖНЫ применяться к терминам, написанным с заглавной буквы в настоящем Уставе.

1. Область действия

Уполномоченная область SMCWG ДОЛЖНА заключаться в обсуждении, принятии и поддержке политик, структур и наборов стандартов, связанных с выдачей и управлением сертификатами S/MIME сторонними центрами сертификации под общедоступным доверенным корнем.

Основной результат должен иметь следующий объем:

• Проверка контроля над адресами электронной почты

• Управление ключами и жизненный цикл сертификатов (при условии координации с другими группами CWG форума для обеспечения согласованности и избежания избыточности)

• Профили сертификатов для сертификатов S/MIME и сертификатов выдающего ЦС (включая уместность расширений и время, когда эти расширения должны присутствовать)

• Операционная практика ЦС, физическая/логическая безопасность и т. д.

В дополнение к основному результату SMCWG МОЖЕТ также рассмотреть:

• Проверка личности физических и юридических лиц в контексте сертификатов S/MIME

Результаты SMCWG ДОЛЖНЫ быть ограничены теми сертификатами, которые содержат защиту электронной почты (OID: 1.3.6.1.5.5.7.3.4) или которые технически допускают такую выдачу.

2. Срок действия чартера

Группа SMCWG создается на неопределенный срок до ее роспуска, как указано в Уставе 5.3.2(c).

3. Персонал и участие

3.1. Подбор офицеров

Стивен Дэвидсон будет председателем SMCWG до первой телеконференции рабочей группы, на которой группа изберет председателя и заместителя председателя. Председатель и заместитель председателя будут работать до 31 октября 2022 г. или до тех пор, пока они не будут заменены, не уйдут в отставку или не будут дисквалифицированы иным образом. После этого выборы председателя и заместителя председателя ДОЛЖНЫ проводиться каждые два года в координации с избирательным процессом Форума и в связи с его избирательным циклом. Голосование ДОЛЖНО происходить в соответствии с Уставом 4.1(c).

3.2. Участие

3.2.1. Право на участие

SMCWG ДОЛЖНА состоять из двух классов членов с правом голоса: эмитентов сертификатов и потребителей сертификатов, отвечающих указанным ниже критериям приемлемости.

<р>1. Эмитент сертификата, имеющий право голоса в SMCWG, ДОЛЖЕН иметь общедоступный отчет об аудите или заявление о подтверждении, основанное на общедоступных критериях аудита или схеме подтверждения, относящейся к выпуску сертификатов S/MIME. Это включает, помимо прочего, следующие схемы и критерии:

o WebTrust для ЦС версии 2.0 или новее; или

o ETSI EN 319 411-1, который включает нормативные ссылки на ETSI EN 319 401 (должна применяться последняя версия упомянутых документов ETSI).

Эти аудиторские отчеты также должны соответствовать следующим требованиям:

o Они должны отчитываться об операционной эффективности средств контроля за исторический период не менее 60 дней;

o Прошло не более 27 месяцев с начала отчетного периода и не более 15 месяцев с момента окончания отчетного периода; и

o Отчет об аудите был подготовлен физическим или юридическим лицом, которое должным образом уполномочено или имеет лицензию на проведение аудита в соответствии с применимыми критериями аудита или используемой схемой аттестации.

Кроме того, эмитент сертификата ДОЛЖЕН активно выпускать сертификаты S/MIME, которые рассматриваются как действительные по крайней мере одним потребителем сертификатов, который создает почтовый пользовательский агент или поставщик услуг электронной почты, обрабатывающий сертификаты S/MIME.

<р>2. Потребитель сертификатов, имеющий право голоса в SMCWG, должен создавать и поддерживать почтовый пользовательский агент (веб-интерфейс или приложение) или поставщик услуг электронной почты, который обрабатывает сертификаты S/MIME.

SMCWG ДОЛЖНА разрешать участие Заинтересованных сторон, как указано в Уставе.

3.2.2. Заявка/декларация о членстве

<р>1. Заявитель, еще не являющийся участником Форума, ДОЛЖЕН предоставить следующую информацию:

o Подтверждение того, что заявитель удовлетворяет хотя бы одному (1) критерию приемлемости для членства (и если он удовлетворяет более чем одному (1), указание единственной категории, по которой заявитель желает подать заявку).

o Название организации, как они хотят, чтобы оно отображалось на веб-сайте Форума и в официальных документах Форума.

o URL-адрес основного веб-сайта заявителя.

o Имена и адреса электронной почты назначенных представителей, которые будут участвовать в Рабочей группе и Форуме от имени Участника.

o Контактная информация для экстренных случаев, связанных с безопасностью сертификатов.

Кандидаты, которые квалифицируются как эмитенты сертификатов или эмитенты корневых сертификатов, должны предоставить следующую дополнительную информацию:

o URL текущего соответствующего аудиторского отчета.

o Ссылки или ссылки на выданные сертификаты конечного объекта, которые демонстрируют, что они рассматриваются как действительные членом-потребителем сертификатов.

Такой заявитель ДОЛЖЕН стать членом после того, как SMCWG на основе консенсуса среди членов во время собрания SMCWG или телеконференции определит, что заявитель соответствует всем вышеперечисленным требованиям, или, по запросу любого члена SMCWG, путем голосования среди Члены SMCWG. Принятие на основе консенсуса определяется или проводится голосование членов, как только заявитель указывает, что он представил всю требуемую информацию, указанную выше, и ответил на все дополнительные вопросы от SMCWG, а член выполнил требования Постановление 5.5.

Кандидаты, выдающие сертификаты, которые не активно выдают сертификаты S/MIME, но в остальном соответствуют этим критериям членства, МОГУТ запросить в SMCWG запрос на предоставление им приглашения для получения статуса Ассоциированного члена в соответствии с Постановлением 3.1 при соблюдении условий, определенных SMCWG.

<р>2. Существующие члены форума CAB, желающие участвовать в SMCWG, в соответствии с Постановлением 5.3.1(c), ДОЛЖНЫ официально заявить о своем намерении участвовать в письменной форме и предоставить председателю SMCWG это заявление и доказательства того, что они соответствуют критериям, изложенным выше. Такие кандидаты ДОЛЖНЫ стать членами SMCWG, как это будет определено на основе консенсуса во время собрания SMCWG или телеконференции, или по запросу любого члена SMCWG путем голосования среди членов SMCWG.

Чтобы подтвердить список первоначальных членов, не менее двух третей организаций из списка предложенных Председателем соответствующих требованиям членов ДОЛЖНЫ публично проголосовать за принятие списка членов. Если первоначальный список не будет принят, Председатель ДОЛЖЕН рассмотреть отзывы и МОЖЕТ в результате обновить первоначальный список предложенных, отвечающих требованиям членов, и будет проведено повторное голосование с использованием тех же правил. Если первоначальный список участников не может быть согласован, SMCWG распускается.

3.2.3. Приостановление и прекращение членства в рабочей группе

Члены могут выйти из SMCWG в любое время. Выход в отставку, приостановка или иное прекращение членства в SMCWG не лишает члена потенциальных продолжающихся обязательств в соответствии с Политикой Форума в области прав интеллектуальной собственности или любым другим документом.

Членство пользователя-потребителя сертификатов может быть приостановлено, если выполняется одно из следующих условий:

<р>1. он прекращает поддержку своего программного продукта, отвечающего критериям членства;

<р>2. его программный продукт, отвечающий требованиям членства, перестает использовать сертификаты S/MIME.

Членство издателя сертификата в SMCWG может быть приостановлено в случае выполнения любого из следующих условий:

<р>1. она не провела и не раскрыла свою квалификационную проверку членства, и прошло пятнадцать (15) месяцев с момента окончания периода аудита ее последней успешной квалификационной проверки членства;

<р>2. его квалификационный аудит членства отозван, аннулирован или отозван;

<р>3. его сертификаты S/MIME не рассматриваются как действительные ни одним членом SMCWG-потребителем сертификатов.

Любой участник, который считает, что одно из вышеуказанных обстоятельств относится к любому другому участнику, может сообщить об этом в общедоступном списке рассылки SMCWG. Затем председатель SMCWG проведет расследование, в том числе попросит участника, о котором сообщается, предоставить доказательства, подтверждающие его квалификацию для членства. Если в течение пяти (5) рабочих дней от участника, о котором заявлено сообщение, не будет получено доказательств сохранения права на членство, председатель SMCWG объявит, что такой участник отстранен от участия, причем в таком объявлении должно быть указано основание, на основании которого было произведено отстранение.

Отстраненный участник, который считает, что он повторно соответствует критериям права на участие, изложенным в этом уставе, должен опубликовать свои доказательства в публичном почтовом списке SMCWG или предоставить доказательства председателю SMCWG, который ДОЛЖЕН опубликовать их в публичном почтовом списке SMCWG. . Председатель SMCWG рассмотрит доказательства и отстранит члена или нет, объявив об этом в список рассылки SMCWG. Членство Участника автоматически прекращается через шесть месяцев после объявления Председателем SMCWG о его приостановлении, если к этому времени Участник повторно не соответствует критериям членства.

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

Голоса, отданные до объявления о приостановке членства, остаются в силе.

4. Заявление о членстве

В соответствии с Политикой защиты прав на интеллектуальную собственность члены, решившие участвовать в SMCWG, ДОЛЖНЫ заявить о своем участии и ДОЛЖНЫ сделать это до участия. Председатель SMCWG ДОЛЖЕН составить список заявлений об участии и вести его в соответствии с Уставом, Политикой ПИС и Соглашением ПИС.

5. Голосование и другие организационные вопросы

5.1. Структура голосования

Правила, описанные в пунктах 2.3 и 2.4 Устава, ДОЛЖНЫ применяться ко всем бюллетеням, включая бюллетени по проектам руководящих принципов.

Чтобы бюллетень был принят SMCWG, две трети или более голосов, поданных эмитентами сертификатов, должны быть за бюллетень, и более 50% голосов, поданных потребителями сертификатов, должны быть в пользу голосования. По крайней мере, один член каждого класса должен проголосовать за бюллетень, чтобы он был принят. Кворум — это среднее количество организаций-членов (в совокупности, независимо от класса), которые участвовали в предыдущих трех (3) собраниях или телеконференциях SMCWG (не считая собраний их подкомитетов). Бюллетени не принимаются до тех пор, пока не будет проведено не менее (3) собраний и не определен кворум.

5.2. Другие организационные вопросы

• Председатель МОЖЕТ при необходимости делегировать любые свои обязанности заместителю председателя. Заместитель Председателя имеет полномочия Председателя в случае любого отсутствия или недоступности Председателя, и в таких обстоятельствах любые обязанности, делегированные Председателю в настоящем документе, МОЖЕТ выполняться Заместителем Председателя. Например, заместитель председателя МОЖЕТ председательствовать на собраниях SMCWG и телеконференциях в его отсутствие.

• SMCWG может учреждать подкомитеты путем официального голосования для решения любых задач SMCWG, указанных в бюллетене (каждый из них именуется «Подкомитет SMCWG»). Подкомитеты SMCWG открыты для всех членов SMCWG. Подкомитет SMCWG может разрабатывать и рекомендовать бюллетени, выполнять делегированные функции или публиковать отчеты для SMCWG, которые входят в сферу действия настоящего устава. Подкомитеты SMCWG должны размещать все повестки дня и протоколы в общедоступном списке рассылки.

6. Сводка основных результатов

Основной результат работы SMCWG указан в разделе «Область применения» и должен включать проект руководства под названием «Базовые требования к выпуску и управлению общедоступными сертификатами S/MIME».

7. Основное средство коммуникации

<р>1. SMCWG ДОЛЖНА назначить веб-мастера для обслуживания страниц SMCWG на вики и общедоступном веб-сайте Форума.

<р>2. SMCWG будет общаться в основном по электронной почте на основе рассылки в соответствии с Постановлением 5.3.1(d). Список SMCWG ДОЛЖЕН быть доступен для общественности, у которой не будет прав на размещение сообщений (т. е. любой может подписаться на получение сообщений, а список может быть просканирован и проиндексирован поисковыми системами Интернета).

<р>3. SMCWG проводит периодические звонки или личные встречи по мере необходимости. Протоколы ДОЛЖНЫ храниться, и такие протоколы ДОЛЖНЫ быть обнародованы в соответствии с Постановлением 5.2.

8. Политика ПИС

Политика интеллектуальных прав CA/Browser Forum, версия 1.3 или более поздняя, ДОЛЖНА применяться ко всей деятельности и участникам рабочей группы.

S/MIME означает безопасные/многоцелевые расширения почты Интернета и обеспечивает дополнительный уровень безопасности электронной почты, отправляемой в и из учетной записи Exchange ActiveSync (EAS). S/MIME позволяет пользователям шифровать исходящие сообщения и вложения, чтобы их могли прочитать только предполагаемые получатели, имеющие цифровую идентификацию (ID), также известную как сертификат. Пользователи могут подписывать сообщения цифровой подписью, что дает получателям возможность проверить личность отправителя и убедиться, что сообщение не было подделано.

О шифровании сообщений

Пользователи могут отправлять зашифрованные сообщения людям в своей организации и людям за ее пределами, если у них есть свои сертификаты шифрования. Однако пользователи, использующие приложение Windows Mail, могут читать зашифрованные сообщения только в том случае, если сообщение получено на их учетную запись Exchange и у них есть соответствующие ключи дешифрования.

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

О цифровых подписях

Сообщение с цифровой подписью убеждает получателя в том, что сообщение не было подделано, и подтверждает личность отправителя. Получатели могут проверить цифровую подпись только в том случае, если они используют почтовый клиент, поддерживающий S/MIME.

Предпосылки

На устройстве установлены действительные сертификаты обмена личной информацией (PFX).

Выберите настройки S/MIME

На устройстве выполните следующие действия: (добавьте выбранный сертификат)

Откройте приложение "Почта".

Откройте "Настройки", коснувшись значка шестеренки на компьютере или многоточия (. ), а затем значка шестеренки на телефоне.

Нажмите "Безопасность электронной почты".

В разделе «Выбор учетной записи» выберите учетную запись, для которой вы хотите настроить параметры S/MIME.

Выберите сертификат для цифровой подписи и шифрования.

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

(Необязательно) Выберите «Всегда подписывать с помощью S/MIME», «Всегда шифровать с помощью S/MIME» или оба варианта, чтобы автоматически ставить цифровую подпись или шифровать все исходящие сообщения.

Параметры подписи или шифрования можно изменить для отдельных сообщений, если только это не запрещено политиками EAS.

Нажмите стрелку назад.

Шифровать или подписывать отдельные сообщения

Во время создания сообщения выберите «Параметры» на ленте. На телефоне к параметрам можно получить доступ, коснувшись многоточия (. ).

Используйте значки "Подписать" и "Зашифровать", чтобы включить цифровую подпись и шифрование для этого сообщения.

Читать подписанные или зашифрованные сообщения

Когда вы получаете зашифрованное сообщение, почтовое приложение проверяет, доступен ли сертификат на вашем компьютере. Если сертификат доступен, сообщение будет расшифровано при его открытии. Если ваш сертификат хранится на смарт-карте, вам будет предложено вставить смарт-карту, чтобы прочитать сообщение. Для смарт-карты также может потребоваться PIN-код для доступа к сертификату.

Установить сертификаты из полученного сообщения

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

Gmail S/MIME API предоставляет программный доступ для управления сертификатами электронной почты S/MIME для пользователей в домене Google Workspace.

Администратор должен включить S/MIME для домена, чтобы сертификаты работали.

Стандарт S/MIME содержит спецификации для шифрования с открытым ключом и подписи данных MIME. Настройка сертификатов S/MIME в учетной записи пользователя приводит к тому, что Gmail использует этот сертификат следующими способами:

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

Вы создаете отдельные сертификаты S/MIME и загружаете их с помощью API. Каждый сертификат S/MIME предназначен для определенного псевдонима учетной записи электронной почты пользователя. Псевдонимы включают в себя основной адрес электронной почты, а также настраиваемые адреса «Отправить как». Один сертификат S/MIME помечается как сертификат по умолчанию для каждого псевдонима.

Авторизация доступа к API

Существует две формы авторизации доступа к API:

Вы можете использовать служебный аккаунт с делегированием полномочий на уровне домена. Объяснение этих терминов см. в разделе Общие термины аутентификации и авторизации. Информацию о том, как включить этот параметр, см. в разделе Создание сервисного аккаунта с делегированием полномочий на уровне домена
Вы можете использовать стандартный поток OAuth2, требующий согласия конечного пользователя для получения маркера доступа Oauth2. Дополнительную информацию см. в разделе Обзор аутентификации и авторизации. Чтобы использовать этот параметр, администратор домена должен установить флажок "Доступ конечных пользователей S/MIME API разрешен" на панели управления доменом.

Области ACL

Этот API использует те же области ACL, что и методы Gmail sendAs:

gmail.settings.basic Эта область требуется для обновления основного S/MIME SendAs. gmail.settings.sharing Эта область необходима для обновления пользовательского из S/MIME.

Использование API

Ресурс users.settings.sendAs.smimeInfo предоставляет методы, которые вы используете для управления сертификатами S/MIME. Каждый сертификат связан с одним псевдонимом отправки как для пользователя.

Загрузить ключ S/MIME

Используйте метод smimeInfo.insert(), чтобы загрузить новый ключ S/MIME для псевдонима, принадлежащего пользователю. Вы определяете целевой псевдоним, используя следующие параметры:

Сертификат S/MIME и закрытый ключ должны присутствовать в поле pkcs12 в этом формате; никакие другие поля не должны быть установлены в запросе. Ожидается, что поле PKCS12 будет содержать как пользовательский ключ S/MIME, так и цепочку сертификатов подписи. API выполняет стандартную проверку этого поля, прежде чем принять его, проверяя следующее:

Тема соответствует указанному адресу электронной почты.
Сроки действия действительны.
Выдающий центр сертификации (ЦС) находится в нашем списке доверенных лиц.
Сертификаты соответствуют техническим ограничениям Gmail.

Если ключ зашифрован, то пароль должен быть в поле зашифрованногоKeyPassword. Успешные вызовы insert() вернут идентификатор smimeInfo, который можно будет использовать для ссылки на ключ в будущем.

Список ключей S/MIME пользователя

Используйте метод smimeInfo.list(), чтобы вернуть список ключей S/MIME для данного пользователя для данного псевдонима. Вы определяете целевой псевдоним, используя следующие параметры:

userId Адрес электронной почты пользователя. Вы можете использовать специальное значение me для указания текущего аутентифицированного пользователя. sendAsEmail Псевдоним, для которого выводятся ключи. Это адрес электронной почты, который отображается в заголовке «От:» для сообщений, отправляемых с использованием этого псевдонима. Ключи возвращаются только в формате pem и содержат только сертификат S/MIME, а не закрытый ключ.

Получить ключи S/MIME для псевдонима

Используйте метод smimeInfo.get(), чтобы вернуть определенные ключи S/MIME для определенного псевдонима "отправить как" для пользователя. Вы определяете целевой псевдоним, используя следующие параметры:

userId Адрес электронной почты пользователя. Вы можете использовать специальное значение me для указания текущего аутентифицированного пользователя. sendAsEmail Псевдоним, для которого вы получаете ключи. Это адрес электронной почты, который отображается в заголовке «От:» для сообщений, отправляемых с использованием этого псевдонима. Ключи возвращаются только в формате pem и содержат только сертификат S/MIME, а не закрытый ключ.

Удалить ключ S/MIME

Используйте метод smimeInfo.delete(), чтобы удалить указанный ключ S/MIME из псевдонима. Вы определяете целевой псевдоним, используя следующие параметры:

userId Адрес электронной почты пользователя. Вы можете использовать специальное значение me для указания текущего аутентифицированного пользователя. sendAsEmail Псевдоним, для которого вы получаете ключи. Это адрес электронной почты, который отображается в заголовке «От:» для сообщений, отправляемых с использованием этого псевдонима. id Неизменяемый идентификатор для SmimeInfo. Удаленный ключ больше не виден и не может быть использован; новая почта, зашифрованная соответствующим открытым ключом, будет нечитаема.

Установите ключ S/MIME по умолчанию для псевдонима

Используйте метод smimeInfo.setDefault(), чтобы пометить указанный ключ S/MIME как ключ по умолчанию для указанного псевдонима. Вы определяете целевой псевдоним, используя следующие параметры:

userId Адрес электронной почты пользователя. Вы можете использовать специальное значение me для указания текущего аутентифицированного пользователя. sendAsEmail Псевдоним, для которого вы получаете ключи. Это адрес электронной почты, который отображается в заголовке «От:» для сообщений, отправляемых с использованием этого псевдонима. id Неизменяемый идентификатор для SmimeInfo. Один и только один ключ S/MIME используется по умолчанию для SendAs пользователя: вызов setDefault() отменит предыдущее значение по умолчанию.

Пример кода

В следующих примерах кода показано использование API для управления сертификатами S/MIME для организации с несколькими пользователями.

Создание ресурса SmimeInfo для сертификата S/MIME

В следующем примере кода показано чтение сертификата из файла, кодирование в строку base64url и присвоение ее полю pkcs12 ресурса smimeInfo:

Питон

Загрузка сертификата S/MIME

Чтобы загрузить сертификат, вызовите smimeInfo.insert и укажите ресурс smimeInfo в теле запроса:

Питон

Примеры управления сертификатами многих пользователей

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

Вставка сертификатов из CSV-файла

Предположим, у вас есть CSV-файл, в котором перечислены идентификаторы пользователей и путь к сертификату каждого пользователя:

Вы можете использовать ранее созданные вызовы createSmimeInfo и insertSmimeInfo для загрузки сертификатов, как указано в CSV-файле:

Питон

Вы можете использовать ранее созданные вызовы create_smime_info и insert_smime_info для загрузки сертификатов, как указано в CSV-файле:

Управление сертификатами

В этом примере объединены несколько вызовов API smimeInfo, чтобы показать, как вы можете управлять сертификатами в своей организации. В нем перечислены сертификаты для пользователя, и если срок действия сертификата по умолчанию истек или он не установлен, он загружает сертификат, найденный в указанном файле. Затем он устанавливает сертификат, срок действия которого ближе всего к будущему, в качестве сертификата по умолчанию.

Затем он вызывается из функции, обрабатывающей CSV-файл, как в предыдущем примере.

Питон

Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

S/MIME (защищенные/многоцелевые расширения почты Интернета) – это широко распространенный протокол для отправки зашифрованных и подписанных в цифровой форме сообщений.Дополнительные сведения см. в разделе S/MIME для подписи и шифрования сообщений в Exchange Online.

S/MIME доступен в Exchange Online для следующих типов почтовых клиентов:

Outlook в Интернете (ранее известное как Outlook Web App) на клиентах Windows. Дополнительные сведения см. в статье Шифрование сообщений с помощью S/MIME в Outlook в Интернете.
Мобильные устройства (например, Outlook для iOS и Android, приложения Exchange ActiveSync или собственные почтовые приложения).

Как администратор Exchange Online, вы можете включить безопасность на основе S/MIME для почтовых ящиков в вашей организации. Шаги высокого уровня описаны в следующем списке и подробно описаны в этой статье:

Настройте и опубликуйте сертификаты S/MIME.
Настройте коллекцию виртуальных сертификатов в Exchange Online.
Синхронизировать пользовательские сертификаты для S/MIME в Microsoft 365.
Настройте политики для установки расширений S/MIME в веб-браузерах для Outlook в Интернете.
Настройте почтовые клиенты для использования S/MIME.

Инструкции по комплексной настройке S/MIME для Outlook для iOS и Android см. в статье S/MIME для Outlook для iOS и Android.

Шаг 1. Настройте и опубликуйте сертификаты S/MIME

Каждому пользователю в вашей организации требуется собственный сертификат, выдаваемый для подписи и шифрования. Вы публикуете эти сертификаты в своей локальной Active Directory для распространения. Ваш Active Directory должен находиться на компьютерах в физическом месте, которое вы контролируете, а не в удаленном объекте или облачной службе в Интернете.

Дополнительную информацию об Active Directory см. в разделе Обзор доменных служб Active Directory.

Установите центр сертификации (ЦС) на базе Windows и настройте инфраструктуру открытых ключей для выдачи сертификатов S/MIME. Также поддерживаются сертификаты, выпущенные сторонними поставщиками сертификатов. Дополнительные сведения см. в разделе Обзор служб сертификации Active Directory.

Примечания:

Сертификаты, выпущенные сторонним ЦС, имеют то преимущество, что им автоматически доверяют все клиенты и устройства. Сертификаты, выданные внутренним частным центром сертификации, не являются автоматически доверенными для клиентов и устройств, и не все устройства (например, телефоны) можно настроить так, чтобы они доверяли частным сертификатам.
Рассмотрите возможность использования промежуточного сертификата вместо корневого сертификата для выдачи сертификатов пользователям. Таким образом, если вам когда-нибудь понадобится отозвать и перевыпустить сертификаты, корневой сертификат останется нетронутым.

Публикуйте сертификат пользователя в его локальной учетной записи Active Directory в атрибутах UserSMIMECertificate и/или UserCertificate.

Шаг 2. Настройте коллекцию виртуальных сертификатов в Exchange Online

Коллекция виртуальных сертификатов отвечает за проверку сертификатов S/MIME. Настройте коллекцию виртуальных сертификатов, выполнив следующие действия:

Экспортируйте корневые и промежуточные сертификаты, необходимые для проверки пользовательских сертификатов S/MIME, с доверенного компьютера в файл сериализованного хранилища сертификатов (SST) в Windows PowerShell. Например:

Подробную информацию о синтаксисе и параметрах см. в разделе Export-Certificate.

Импортируйте сертификаты из файла SST в Exchange Online, выполнив следующую команду в Exchange Online PowerShell:

Для получения подробной информации о синтаксисе и параметрах см. Set-SmimeConfig.

Шаг 3. Синхронизируйте пользовательские сертификаты для S/MIME с Microsoft 365

Прежде чем кто-либо сможет отправлять сообщения, защищенные с помощью S/MIME, в Exchange Online, вам необходимо установить и настроить соответствующие сертификаты для каждого пользователя и опубликовать их общедоступные сертификаты X.509 в Microsoft 365. Почтовый клиент отправителя использует общедоступный сертификат получателя. чтобы зашифровать сообщение.

Выпускайте сертификаты и публикуйте их в локальной Active Directory. Дополнительные сведения см. в разделе Обзор служб сертификации Active Directory.

После публикации сертификатов используйте Azure AD Connect для синхронизации пользовательских данных из локальной среды Exchange с Microsoft 365. Дополнительные сведения об этом процессе см. в статье Синхронизация Azure AD Connect: понимание и настройка синхронизации.

Наряду с синхронизацией других данных каталога Azure AD Connect синхронизирует атрибуты userCertificate и userSMIMECertificate для каждого объекта пользователя для подписи S/MIME и шифрования сообщений электронной почты. Дополнительные сведения об Azure AD Connect см. в статье Что такое Azure AD Connect?

Шаг 4. Настройте политики для установки расширений S/MIME в веб-браузерах

Этот шаг требуется только для Outlook в веб-клиентах.

S/MIME в Outlook в Интернете в Microsoft Edge на базе Chromium или в Google Chrome требует определенных параметров политики, которые настраиваются администратором.

Подробнее о правилах см. в следующих темах:

Эта политика необходима для использования S/MIME в Outlook в Интернете.Он не заменяет элемент управления S/MIME, установленный пользователями. Пользователям предлагается загрузить и установить элемент управления S/MIME в Outlook в Интернете при первом использовании S/MIME. Или пользователи могут заблаговременно перейти к S/MIME в настройках Outlook в Интернете, чтобы получить ссылку для скачивания элемента управления.

Шаг 5. Настройте почтовые клиенты для использования S/MIME

Если почтовый клиент поддерживает S/MIME, следующим вопросом является доступ к сертификату S/MIME пользователя этим почтовым клиентом. Сертификат S/MIME должен быть установлен на компьютере или устройстве пользователя. Вы можете распространять сертификаты S/MIME автоматически (например, с помощью Microsoft Endpoint Manager) или вручную (например, пользователь может экспортировать сертификат со своего компьютера и импортировать его на свое мобильное устройство). После того, как сертификат будет доступен локально, вы сможете включить и настроить S/MIME в настройках почтового клиента.

Дополнительную информацию о S/MIME в почтовых клиентах см. в следующих разделах:

Outlook. См. раздел "Шифрование с помощью S/MIME" в статье Шифрование сообщений электронной почты.
Outlook для iOS и Android: включение S/MIME в клиенте
Почта в iOS: используйте S/MIME для отправки зашифрованных сообщений в среде Exchange в iOS

Вы также можете использовать следующие параметры командлетов New-MobileDeviceMailboxPolicy и Set-MobileDeviceMailboxPolicy в Exchange Online PowerShell для настройки параметров S/MIME для мобильных устройств:

В этой статье описываются требования, которым должен соответствовать каждый сертификат в цепочке X.509, чтобы быть доверенным для использования с зашифрованной электронной почтой или электронной почтой, подписанной S/MIME.

Помимо этих требований, цепочка должна быть привязана к сертификату центра сертификации (ЦС), которому Google явно доверяет для этой цели. Вы также можете принять корневые сертификаты от центров сертификации, которым вы доверяете. Дополнительные сведения см. в руководстве по корневым сертификатам.

Примечания:

Google предоставляет и поддерживает список сертификатов ЦС, которым Gmail доверяет для S/MIME. Список ЦС является доверенным исключительно по усмотрению Google. Google оставляет за собой право удалять корневые центры сертификации в любое время без предварительного уведомления.
Убедитесь, что установленные расширения не противоречат другим расширениям в том же сертификате. Например, если определены nsCertTypes, они должны охватывать те же области применения, что и расширение использования ключа, расширение расширенного использования ключа и расширение основных ограничений.

Правила цепочки сертификатов

Корневой центр сертификации

Должен идентифицировать ЦС.

Например, DN не должно быть общим значением, таким как "Центр сертификации".

Закодированная форма должна быть побайтно идентична DN издателя.

Информация об открытом ключе субъекта

rsaEncryption с модулем RSA 2048, 3072 или 4096. Или ecPublicKey с использованием secp256r1 или secp384r1.

Сертификаты промежуточного ЦС, отличные от сертификатов промежуточного ЦС

Используйте эту информацию, если между корневым и конечным объектами прямо или косвенно находится более одного промежуточного ЦС.

Выдающий промежуточный ЦС — это промежуточный ЦС, выдающий сертификат конечного объекта. Этот раздел применим к любым промежуточным ЦС в цепочке, кроме выдающего промежуточного ЦС.

Должен быть побайтно идентичен DN субъекта выпускающего ЦС.

rsaEncryption с модулем RSA 2048, 3072 или 4096. Или ecPublicKey с использованием secp256r1 или secp384r1

Битовые позиции должны быть установлены для: keyCertSign
Могут быть установлены любые другие битовые позиции

4.9.7. Частота выдачи CRL
4.9.9. Доступность отзыва/проверки состояния в режиме онлайн

4.9.10. Требования к онлайн-проверке отзыва
4.10.2 Доступность службы

Сертификат промежуточного ЦС, выдающий конечный объект

Важно! В цепочке должен присутствовать хотя бы один промежуточный сертификат ЦС. То есть корень не должен выдавать сертификаты конечного объекта напрямую.

Должен быть побайтно идентичен DN субъекта выпускающего ЦС.

Разница между notBefore и notAfter

Не должен превышать 10 лет и не должен превышать 20 лет.

Должен указывать на использование ЦС.

rsaEncryption с модулем RSA 2048, 3072 или 4096. Или ecPublicKey с использованием secp256r1 или secp384r1

Битовые позиции должны быть установлены для:
keyCertSign
Битовые позиции могут быть установлены для:
cRLSign
digitalSignature
Если они используются непосредственно для подписи ответов OCSP, должны быть присутствует:
цифровая подпись

Другие битовые позиции устанавливать нельзя

поле cA должно иметь значение true
поле pathLenConstraint ДОЛЖНО присутствовать и ДОЛЖНО быть равно 0

Серверы отзыва должны работать в соответствии со следующими разделами Политики сертификатов базовых требований CA/Browser Forum для выдачи общедоступных сертификатов и управления ими версии 1.3.2 или выше: р>

4.9.7. Частота выдачи CRL
4.9.9. Возможность онлайн-аннулирования/проверки статуса
4.9.10. Требования к онлайн-проверке отзыва
4.10.2. Доступность службы

Сертификат конечного объекта

Должно быть больше нуля (0) и содержать не менее 64 непредсказуемых битов.

Примечание: будет обновлено, чтобы отразить Основные требования CA/Browser Forum Certificate Policy требования к энтропии серийного номера конечного объекта.

Должен быть побайтно идентичен DN субъекта выпускающего ЦС.

Разница между значениями notBefore и notAfter не должна превышать 27 месяцев.

Время notBefore должно соответствовать времени подписи плюс-минус 48 часов.

Любые относительные отличительные имена субъекта, кроме адреса электронной почты, должны быть тщательно проверены перед выдачей с использованием публично задокументированной и проверенной процедуры. См. раздел 3.2.3 «Аутентификация личности» Политики CA/Browser Forum по базовым требованиям к сертификатам для выдачи и управления общедоступными сертификатами версии 1.3.2 или более поздней для получения информации о приемлемой процедуре. .

Любые адреса электронной почты (например, в полях commonName или emailAddress) также должны присутствовать в расширении альтернативного имени субъекта в виде rfc822Name.

rsaEncryption с модулем RSA 2048, 3072 или 4096. Или ecPublicKey с использованием secp256r1 или secp384r1

Битовые позиции должны быть установлены для:
digitalSignature
и/или
nonRepudiation/contentCommitment
Битовые позиции могут быть установлены для:
dataEncipherment
шифрование ключей

Другие битовые позиции устанавливать нельзя.

Битовые позиции должны быть установлены для:
digitalSignature
Битовые позиции могут быть установлены для:
nonRepudiation/contentCommitment
keyAgreement
encipherOnly (если установлено keyAgreement) < br />decipherOnly (если установлено keyAgreement)

Другие битовые позиции устанавливать нельзя.

При наличии поле cA не должно быть установлено значение true
поле pathLenConstraint не должно присутствовать

Должен присутствовать: должен быть указан policyIdentifier, который идентифицирует политику, в соответствии с которой был выпущен сертификат, и не должен быть anyPolicy.

Доступ к авторитетной информации

AccessDescription не должен содержать меток или параметров, относящихся к отдельному сертификату.

4.9.7. Частота выдачи CRL
4.9.9. Возможность онлайн-аннулирования/проверки статуса
4.9.10. Требования к онлайн-проверке отзыва
4.10.2. Доступность службы

Альтернативное имя субъекта

Должен содержать хотя бы один элемент типа rfc822Name.
Не должно содержать элементов типа:
dNSName
iPAddress
uniformResourceIdentifier
Каждое имя rfc822Name должно быть проверено с помощью публично задокументированных и проверенных мер, чтобы гарантировать, что объект, отправляющий запрос, контролирует учетная запись электронной почты, связанная с адресом электронной почты или уполномоченная владельцем учетной записи электронной почты действовать от имени владельца учетной записи.

Читайте также: