Ssl сертификат клиентский: Клиентский SSL сертификат: для чего используется

Клиентский SSL сертификат: для чего используется

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

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

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

Как получить клиентский сертификат?

Самый лучший способ получить клиентский сертификат – это воспользоваться приложением OpenSSL.

OpenSSL – популярный инструмент, который активно используется разными компаниями для управления сертификатами: получения самоподписанных сертификатов ЦС (центра сертификации), управления сертификатами сервера, сертификатами пользователя и отозванными сертификатами.

Как происходит авторизация клиентов?

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

Яркий пример такой авторизации – это платежная система WebMoney Transfer с ее клиентом WM Keeper Light. Подобная схема авторизации является очень надежной, поэтому она активно применяется в банковской сфере.

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

1. Получить свой собственный доверенный сертификат Certificate Authority, чтобы потом с его помощью подписывать и верифицировать клиентские сертификаты.
2. Создать клиентские сертификаты, которые затем будут передаваться клиентам. Такие сертификаты должны быть подписаны доверенным сертификатом.
3. Настроить сервер, чтобы он должным образом запрашивал и верифицировал клиентские SSL-сертификаты.

Работа с ключами обычно осуществляется при помощи утилиты OpenSSL, про которую мы писали в следующей статье.

Клиентский SSL-сертификат вы всегда можете приобрести в компании ЛидерТелеком, выбрав для себя подходящий вариант по оптимальной цене.

Сертификаты клиентов и сертификаты сервера. В чем разница?

Настройка сертификатов аутентификации клиентов в веб-браузерах

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

Это руководство покажет вам, как использовать клиентские сертификаты с самыми популярными настольными браузерами. В этих инструкциях предполагается, что вы уже загрузили и установили файл PFX / PKCS12 с вашим сертификатом и закрытым ключом, или у вас есть аппаратный токен с сертификатом и закрытым ключом, вставленным в компьютер.

Google Chrome, Microsoft Edge, Internet Explorer, Apple Safari

Chrome, Edge, IE и Safari настроены на использование клиентских сертификатов и закрытых ключей, предоставляемых ОС. Сюда входят файлы PFX, импортированные в хранилище сертификатов ОС, а также сертификаты и закрытые ключи, хранящиеся на смарт-картах (включая SSL.com Идентичность бизнеса сертификаты). Итак, если вы установили свой файл PFX или ваш USB-токен вставлен в компьютер, вы уже должны быть готовы пройти аутентификацию клиента с помощью этих популярных настольных браузеров.

Подтвердите установку

Вы можете проверить, что установленные сертификаты аутентификации клиента доступны для вашего браузера, перейдя к https://server.cryptomix.com/secure/, Если сертификаты присутствуют, появится диалоговое окно со списком их.

Mozilla Firefox

Использовать хранилище сертификатов ОС (Firefox 75 и новее)

Начиная с версия 75Firefox может быть настроен на использование клиентских сертификатов и закрытых ключей, предоставляемых ОС в Windows и macOS. Этот метод поддерживает как файлы PFX, импортированные в хранилище сертификатов ОС, так и сертификаты и закрытые ключи, хранящиеся на смарт-картах (включая SSL.com). Идентичность бизнеса сертификаты). В общем, сейчас это предпочтительный и самый простой способ использования клиентских сертификатов в Firefox.

1. Откройте Firefox и перейдите к about:config в адресной строке.
   
2. При появлении запроса нажмите Принять риск и продолжить.
   
3. Тип security.osclientcerts.autoload в поле поиска.
   
4. Нажмите Переключать Кнопка на правой стороне экрана.
   
5. security. osclientcerts.autoload теперь установлено true, разрешающий использование сертификатов, предоставляемых операционной системой Windows и macOS.
   
6. Вы можете проверить, что Firefox может просматривать сертификаты, предоставленные ОС, перейдя к about:preferences#privacy, затем прокрутите вниз и нажмите Просмотр сертификатов кнопку.
   
7. Выберите Ваши сертификаты вкладка для отображения списка личных сертификатов, предоставляемых ОС.
   

Установите клиентские сертификаты в Firefox

Вы также можете установить сертификат и закрытый ключ непосредственно в собственное хранилище сертификатов Firefox, импортировав файл PFX / PKCS12, как описано ниже. Этот метод не подходит для сертификатов с неэкспортируемыми закрытыми ключами, хранящимися на смарт-картах, включая SSL.com. Электронный адрес, ClientAuth и подпись документов сертификаты.

1. Откройте Firefox и перейдите к about:preferences#privacy, затем прокрутите вниз и нажмите Просмотр сертификатов кнопку.
   
2. Выберите Ваши сертификаты , затем нажмите Импортировать кнопку.
   
3. Перейдите к файлу PFX, затем нажмите Откройте кнопку.
   
4. Введите пароль, который вы создали при загрузке файла PFX с SSL.com, затем щелкните OK кнопку.
   
5. Сертификат теперь установлен в Firefox. Закрыть диалоговое окно, нажав OK кнопку.
   

Подтвердите установку

Вы можете проверить, что установленные сертификаты аутентификации клиента доступны для Firefox, перейдя к https://server.cryptomix.com/secure/, Если сертификаты присутствуют, появится диалоговое окно со списком их.

Авторизация по SSL сертификатам | r-notes.ru

Протокол SSL позволяет организовать доступ к сайту (или его части) путем авторизации по клиентским сертификатам. При попытке входа  на защищенный ресурс, сервер запрашивает у клиента сертификат. Если проверка сертификата проходить успешно, клиент получает доступ к защищенным ресурсам.

Весьма удобно.

Реализовать этот механизм можно с помощью Apache и его модуля mod_ssl. Для этого понадобится:

Конфигурация сервера для запроса и проверки клиентских сертификатов

Настроим один из серверов, рассмотренных в предыдущей статье, для авторизации по клиентским сертификатам. К примеру citename.ru. CA для него уже создан. По этому начнем с настройки виртуального хоста. В файл настроек нужно добавить следующее:

SSLCACertificateFile	Абсолютный путь к файлу доверенного сертификата (CA)
SSLVerifyClient require	Требование предоставить сертификат для авторизации. Если сертификат не будет предоставлен — доступ будет запрещен.

Секция VirtualHost для citename.ru должна выглядеть так:

Теперь можно сказать Apache перечитать конфигурацию

# /etc/init.d/apache2 reload

Создание клиентского сертификата

Подготовим структуру каталогов и файлов для хранилища сертификатов.

# mkdir /etc/ssl/citename.ru
# cd /etc/ssl/citename.ru
# mkdir db
# mkdir db/certs
# mkdir db/newcerts
# touch db/index.txt
# echo "01" > db/serial
# chmod 700 ./

В каталоге db/certs будем хранить выданные сертификаты. В файле db/index.txt будут храниться данные о выданных сертификатах. А в файле db/serial — серийный номер для нового сертификата.

Создаем конфигурационный файл для подписи сертификатов.

Создаем запрос на клиентский сертификат.

# openssl req -new -newkey rsa:1024 -nodes -keyout user01.key -days 365 \
          -subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=Sales/CN=user01/emailAddress=userЭтот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра." \
          -out user01.csr

Аргументы команды:

req	Генерация нового сертификата
-new	Запрос на подпись сертификата
-newkey rsa:1024	Новый закрытый RSA ключ длиной 1024 бита
-nodes	Не шифровать закрытый ключ
-keyout user01. key	Закрытый ключ сохранить в user01.key
-days 365	Срок действия сертификата
-subj	Информация о владельце сертификата.
	C — Двухсимвольное обозначение страны ST — Республика/Регион/Край/Область L — Населённый пункт O — Организация OU — Подразделение организации CN — Имя сертификата. Если генерится для сервера — должно указываться имя сервера. emailAddress — и так вроде понятно
-out user01.csr	Запрос на сертификат сохранить в user01.csr

Результатом команды будут два файла: закрытый ключ user01.key и запрос на сертификат user01.csr. Проверим что у нас получилось.

# openssl req -noout -text -in user01.csr

Certificate Request:     Data:         Version: 0 (0x0)         Subject: C=RU, ST=Arkh, L=Arkh, O=OAO, OU=Sales, CN=user01/emailAddress=Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.         Subject Public Key Info:             Public Key Algorithm: rsaEncryption                 Public-Key: (1024 bit)                 Modulus:                     00:d9:18:df:76:81:90:3b:f1:2f:05:bd:e1:bc:a1:                     a8:0f:6d:ad:92:8c:ae:86:28:79:16:db:6a:7f:1a:                     d7:38:98:78:e3:52:70:26:9a:b2:9c:1f:80:f7:d6:                     99:82:f7:55:7d:a2:57:78:63:28:cd:70:93:96:a6:                     d3:40:55:20:d0:45:f2:7d:8f:d1:83:0d:50:2b:d3:                     ed:71:c6:2d:af:0a:8b:92:55:2b:25:17:22:3d:71:                     db:ee:ef:95:e7:52:d6:aa:46:31:e2:ee:c5:09:78:                     d4:78:a7:f0:f0:0b:4f:bb:38:2b:3b:2d:46:99:49:                     6b:aa:42:e0:67:7c:1c:4c:5b                 Exponent: 65537 (0x10001)         Attributes:             a0:00     Signature Algorithm: sha1WithRSAEncryption          14:81:32:d3:32:ef:a8:fd:03:7a:91:0c:7c:73:b7:9c:a8:59:          3a:18:27:30:48:6a:0c:9a:47:1f:91:12:2e:5a:8e:fd:15:37:          05:c4:6f:04:16:51:f0:7b:b6:50:ce:08:b1:ce:5f:e6:4a:a1:          f2:df:c5:e6:fb:cd:29:2d:32:fc:6b:cc:52:52:f6:ba:4b:88:          d3:cd:97:14:7c:49:f5:03:82:ca:14:74:d0:6f:20:07:bc:8e:          42:41:3c:61:17:a5:36:32:e8:08:95:18:c7:f8:63:5f:18:82:          76:70:65:b1:c9:fe:d9:5d:e3:cf:f8:c4:08:54:dd:ca:af:f5:          77:96

# openssl rsa -noout -text -in user01. key

Подпишем сертификат ключом сервера.

openssl ca -config citename-CA.conf -in user01.csr -out user01.crt -batch

Результатом команды будет вывод на экран что-то вроде этого:

И файл подписанного сертификата user01.crt.

Аргументы команды:

ca	Подпись запроса на сертификат доверенным сертификатом
-config citename-CA. conf	Использовать конфигурационный файл citename-CA.conf
-in user01.csr	Файл запроса на сертификат находится в user01.csr
-out user01.crt	Подписанный сертификат сохранить в user01.crt
-batch	Не задавать вопросов и автоматически сертифицировать

Проверим что получилось.

# openssl x509 -noout -text -in user01.crt

Certificate:     Data:         Version: 1 (0x0)         Serial Number: 2 (0x2)     Signature Algorithm: md5WithRSAEncryption         Issuer: C=RU, ST=Arkh, L=Arkh, O=OAO, OU=Sales, CN=citename.ru/emailAddress=Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.         Validity             Not Before: Jan 30 18:58:53 2018 GMT             Not After : Jan 30 18:58:53 2016 GMT         Subject: C=RU, ST=Arkh, L=Arkh, O=OAO, OU=Sales, CN=user01/emailAddress=Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.         Subject Public Key Info:             Public Key Algorithm: rsaEncryption                 Public-Key: (1024 bit)                 Modulus:                     00:d9:18:df:76:81:90:3b:f1:2f:05:bd:e1:bc:a1:                     a8:0f:6d:ad:92:8c:ae:86:28:79:16:db:6a:7f:1a:                     d7:38:98:78:e3:52:70:26:9a:b2:9c:1f:80:f7:d6:                     99:82:f7:55:7d:a2:57:78:63:28:cd:70:93:96:a6:                     d3:40:55:20:d0:45:f2:7d:8f:d1:83:0d:50:2b:d3:                     ed:71:c6:2d:af:0a:8b:92:55:2b:25:17:22:3d:71:                     db:ee:ef:95:e7:52:d6:aa:46:31:e2:ee:c5:09:78:                     d4:78:a7:f0:f0:0b:4f:bb:38:2b:3b:2d:46:99:49:                     6b:aa:42:e0:67:7c:1c:4c:5b                 Exponent: 65537 (0x10001)     Signature Algorithm: md5WithRSAEncryption          72:e5:e6:7d:e2:c1:fd:63:d1:55:72:96:2c:92:e2:1b:7f:b8:          fc:d7:0e:ce:72:dc:24:3d:f4:db:27:79:26:c8:17:15:7f:fe:          c4:36:6e:32:9e:40:20:c5:b6:30:ae:ee:3c:12:36:3a:45:1b:          cc:d5:92:f6:72:d7:9d:84:b8:71:16:03:26:a9:2b:43:2a:68:          06:91:ff:76:5b:46:98:07:18:d5:2f:2c:81:97:5c:80:f7:1d:          55:d5:13:2e:25:10:82:ea:33:13:3c:a5:1d:c2:18:dd:e5:7c:          f0:05:1e:ae:2a:80:01:3f:69:f4:c5:7f:da:18:b8:e9:29:90:          67:0c

Подготовим сертификат для передачи пользователю.

# openssl pkcs12 -export -in user01.crt -inkey user01.key -out user01.p12 \
        -certfile /etc/apache2/ssl/citename-CA.crt -passout pass:passwordkey

 Аргументы команды:

Клиентский сертификат готов. Хранится он в файле user01.p12. Теперь его можно передать пользователю для установки в браузер.

Переместим все созданные файлы в каталог db/certs на хранение.

# mv . /user01.* db/certs/

Скрипт для создания клиентских сертификатов

Если сертификаты нужно создавать на регулярной основе — можно воспользоваться скриптом

Для корректной работы скрипта требуется наличие установленных программ: mail-client/mailx (mail — консольный клиент для отправки почтовых сообщений, app-arch/rar (архиватор), app-arch/sharutils (перекодировщик двоичных файлов в текстовый вид для почтовых вложений).

Аутентификация клиентскими SSL сертификатами

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

Разрешить регистрацию SSL сертификатов пользователей: Разрешает или запрещает удаленным пользователям самостоятельно регистрировать свои SSL сертификаты для связывания их со своими учетными записями Парус 8.

Наименование и примечание внешнего поставщика информационных услуг : указанный поставщик будет использоваться для ассоциации учетных записей пользователей с отпечатками (thumbprint) клиентских SSL сертификатов.

В случае отсутствия указанного поставщика в БД, он будет создан во время сохранения конфигурации. Посмотреть существующие поставщики можно в интерфейсе Парус 8: Администратор -> Учет -> Внешние поставщики информационных услуг.

Посмотреть информацию о привязанных SSL сертификатах к текущему пользователю сервиса, а также удалить некоторые из них, можно в Web-интерфейсе: Первичные отчеты -> Действия (или контекстное меню) -> Расширения -> Логины внешних провайдеров.

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

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

Список отозванных сертификатов : При необходимости, укажите путь к файлу в PEM-формате, содержащий отозванные сертификаты (признаваемые недействительными раньше срока своего окончания).

Получение CRL файла в PEM формате.

Если используется собственный центр сертификации на основе инфраструктуры OpenSSL:

openssl ca -gencrl -out ca.crl

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

Просмотр с помощью OpenSSL, при условии, что файл сертификата в PEM формате (в примере просматривается сертификат c:\ca.pem):

openssl x509 -noout -text -in c:\ca.pem

Просмотр с помощью средств Windows (файл сертификата может быть в любом формате, но должен иметь раширение.crt):

1. Открываем файл сертификата в проводнике
2. В открывшемся диалоге свойств сертификата переходим на вкладку Details
3. Среди свойств сертификата выбираем CRL Distribution Points
4. Копируем URL из значения этого свойства

После скачивания CRL файла по полученному URL, его необходимо сконвертировать в PEM формат (в примере исходный файл в DER формате — crl.der, итоговый файл в PEM формате — crl.pem):

openssl crl -inform DER -in crl.der -outform PEM -out crl.pem

Глубина проверки в цепочке сертификатов : Укажите глубину проверки в цепочке сертификатов. Глубина проверки устанавливает лимит на количество сертификатов между конечным сертификатом пользователя и доверенным центром, находящимся в файле доверенных центров сертификации. Если цепочка сертификатов, необходимая для получения доверенного эмитента, длиннее указанной глубины + 2, то пользовательский сертификат будет признан недействительным.

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

Авторизация клиентов с помощью SSL сертификатов — «IT- Free»

1. Создание самоподписного доверенного сертификата

Самоподписный доверенный сертификат (Certificate Authority или CA) необходим для подписи серверных и клиентских сертификатов, для их проверки при авторизации вашим веб-сервером.

Создаем самоподписанный сертификат и ключ.

openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 365\ 
-subj/C=RU/ST=Msc/L=Msk/O=ItFree/OU=User/CN=it-free.ru/[email protected] -out ca.crt

Описание аргументов:

req
запрос на создание нового сертификата.

-new 
создание запроса на сертификат (CSR).

-newkey rsa:1024 

создаем закрытый RSA ключ длиной 1024 бита, длина ключа по Вашему усмотрению.

-nodes
не шифровать закрытый ключ

-keyout ca.key
сохраняем ключ в файл ca.key.

-x509 
вместо создания запроса на сертификат, создаем самоподписанный сертификат.

-days 350 
срок действия сертификата 350 дней.

-subj/C=RU/ST=Msc/L=Msk/O=ItFree/OU=User/CN=it-free.ru/[email protected] -out ca.crt

параметры:

С — код страны (Country). 
ST — название региона/области/края/республики/… (StateName). 
L — название города/поселка/… (LocalityName). 
O — название организации (OrganizationName).
OU — название отдела (OrganizationUnit). 
CN — имя сертификата, при создании серверных сертификатов используется доменное имя сайта, для клиентских
сертификатов может быть использовано что угодно (CommonName). Обязательный параметр.
emailAddress — почтовый адрес (E-mail address).

2. Создаем сертификат для веб-сервера

Создаем зашифрованный ключ и запрос на сертификат

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr

Подпишем запрос и получим сертификат

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

Если не хотите чтобы веб-сервер спрашивал пароль после перезагрузки

openssl rsa -in server.key -out server.nopass.key

3. Настройка веб-сервера (Apache)

Найдите в настройках Вашего веб-сервера соответствующую запись для вашей защищаемой страницы и поместите следующие строки

SSLCACertificateFile /path/to/youcakey/ca.crt

<Directory /path/to/web/>

 SSLVerifyClient require
 SSLRequireSSL

</Directory>

4. Создание клиентских сертификатов

Создаем файл ca.config

[ ca ]
default_ca = CA_CLIENT # использовать секцию CA_CLIENT

[ CA_CLIENT ]
dir = ./db # рабочий каталог
certs = $dir/certs # каталог для создаваемых сертификатов
new_certs_dir = $dir/newcerts # каталог для новых сертификатов

database = $dir/index.txt # база данных подписанных Вами сертификатов
serial = $dir/serial # серийный номер сертификата в шестнадцатиричном формате
certificate = ./ca.crt # файл сертификата CA
private_key = ./ca.key # файл закрытого ключа CA

default_days = 365 # срок действия подписываемого сертификата
default_crl_days = 7 # срок действия CRL
default_md = md5 # алгоритм подписи

policy = policy_anything # название секции с описанием политики в отношении данных сертификата

[ policy_anything ]
countryName = optional # поля optional — не обязательны, supplied — обязательны
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

Создаем рабочие каталоги и файлы указанные в ca.config

mkdir db
mkdir db/certs
mkdir db/newcerts
touch db/index.txt
echo «01» > db/serial

Создаем шифрованный ключ и запрос на сертификат

openssl req -new -newkey rsa:1024 -nodes -keyout client01.key\ 
-subj /C=RU/ST=Msc/L=Msc/O=ItFree/OU=User/CN=Client01/[email protected] -out client01.csr

Подписываем запрос и создаем сертификат

openssl ca -config ca.config -in client01.csr -out client01.crt -batch

Для раздачи сертификата клиента создаем p12 с паролем q1w2e3

openssl pkcs12 -export -in client01.crt -inkey client01.key -certfile ca.crt -out client01.p12 -passout pass:q1w2e3

Авторизация по клиентским TLS/SSL сертификатам в NGINX — Geek Notes

Простой и удобный способ авторизации на сайте или в приложениях по клиентским TLS/SSL сертификатам.

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

Шаг 1. Создание центра сертификации

Чтобы приступить к работе сперва необходимо настроить центр сертификации (CA), это довольно просто. Если на сервере установлен OpenSSL, то СА по умолчанию настроен и готов к работе. Теперь создадим свой собственный доверенный сертифика, он необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.

Шаг 1.2. Создаем приватный ключ центра сертификации.

openssl genrsa -out ca.key 4096

Шаг 1.3. Создаем самоподписанный сертификат.

openssl req -new -sha256 -x509 -days 1095 -key ca.key -out ca.crt

Шаг 2. Создание сертификата сервера

Шаг 2.1 Создаем приватный ключ для веб-сервера.

openssl genrsa -out server.key 4096

Шаг 2.2. Создаем сертификат для веб-сервера.

openssl req -new -key server.key -sha256 -out server.csr

Шаг 2.3. Подписываем сертификат веб-сервера нашим центром сертификации.

openssl x509 -req -days 1095 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 0x`openssl rand 16 -hex` -sha256 -out server.pem

Шаг 3. Создание клиентского сертификата

Шаг 3.1. Создаем клиентский приватный ключ по тому же принципу.

openssl genrsa -out client.key 4096

Шаг 3.2. Создаем клиентский сертификат.

openssl req -new -key client.key -sha256 -out client.csr

Шаг 3.3. Подписываем сертификат нашим центром сертификации.

openssl x509 -req -days 1095 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 0x`openssl rand 16 -hex` -sha256 -out client.pem

Шаг 4. Создание сертфиката в формате PKCS#12 для браузеров.

openssl pkcs12 -export -in client.pem -inkey client.key -name "Sub-domain certificate for some name" -out client.p12

Добавляем сертификаты в систему на примере MacOS

Загружаем client.p12 и установим его в систему.

Переходим в связку ключей и в свойствах установленного сертификата меняем уровень доверия на “Всегда доверять”.

Раскрываем ветку сертификата и предоставляем полный доступ для программ в его свойствах:

Для того, чтобы соединение было доверенным между сервером и клиентом, то обязательно установим корневой сертификат на клиентское устройство (ca.crt)

клиентских сертификатов и серверных сертификатов — в чем разница?

Шифрование защищает данные во время передачи

или SSL выполняют очень похожую роль на сертификаты клиентов, за исключением того, что последний используется для идентификации клиента / человека, а первый аутентифицирует владельца сайта. Сертификаты сервера обычно выдаются именам хостов, которые могут быть именем компьютера (например, «XYZ-SERVER-01») или именем домена (например, «www.digicert.com ’). Веб-браузер подключается к серверу и проверяет подлинность сертификата сервера SSL. Это говорит пользователю, что при его взаимодействии с веб-сайтом нет перехватчиков и что веб-сайт является именно тем, кем он себя называет. Эта безопасность критически важна для электронной коммерции, поэтому сертификаты сейчас так широко используются.

Как они это делают? На практике оператор веб-сайта получает сертификат, обратившись к провайдеру сертификата с запросом на подпись сертификата.Это электронный документ, содержащий всю важную информацию: название веб-сайта, контактный адрес электронной почты и информацию о компании. Провайдер сертификата подписывает запрос, создавая публичный сертификат, который предоставляется любому веб-браузеру, который подключается к веб-сайту, и, что особенно важно, доказывает веб-браузеру, что провайдер выдал сертификат человеку, который, по его мнению, является владельцем веб-сайт. Однако перед выдачей сертификата провайдер сертификата запросит контактный адрес электронной почты для веб-сайта у регистратора общедоступных доменных имен и сверит опубликованный адрес с адресом электронной почты, указанным в запросе сертификата, обеспечивая закрытие круга доверия.

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

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

ПОДРОБНЕЕ

и сертификат сервера: упрощая разницу

Давайте разберемся в фундаментальных различиях между сертификатами клиента и сертификатами сервера

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

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

Приступим!

Услышав эти два термина, нельзя не подумать, что «клиентский» сертификат должен быть связан с клиентом, а «серверный» сертификат — с сервером. Это не совсем правильно, но это хорошее место для начала.

Сертификат сервера

Сертификаты сервера (сертификаты SSL) используются для проверки подлинности сервера. При установке на веб-сайт SSL-сертификат переключает протокол на веб-сайте с HTTP на HTTPS [Разница между HTTP и https] и устанавливает индикаторы, подтверждающие подлинность веб-сайта.Таким образом, пользователи могут знать, что веб-сайт принадлежит указанному лицу. Помимо аутентификации, SSL-сертификаты также способствуют шифрованию. Это означает, что любая информация, которую пользователь отправляет на сервер, защищена от злонамеренных сторон 3 ^rd .

Сертификат клиента

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

В отличие от сертификатов сервера (сертификаты SSL), сертификаты клиента используются для проверки личности клиента (пользователя). В этом случае пользователь может быть пользователем веб-сайта или электронной почты. Проще говоря, он работает как пароль, но без какого-либо вмешательства / ввода со стороны пользователя. Таким образом, сервер гарантирует, что он подключается к разрешенному пользователю и с этой стороной безопасно общаться.

Теперь вы можете спросить: «Разве пароли не делают одно и то же?» Что ж, иногда паролей недостаточно.Мы часто становимся жертвами таких методов взлома паролей, как атаки методом перебора и клавиатурные шпионы. Вот почему паролей уже недостаточно, когда на карту поставлена ​​действительно конфиденциальная информация.

Итак, могут быть некоторые документы или файлы, к которым вы хотите получить доступ только определенным людям. Но поскольку пароли недостаточно надежны, вам придется изучить возможные варианты. Вот тут и пригодятся клиентские сертификаты. Вместо проверки людей с помощью паролей клиентские сертификаты аутентифицируют людей с помощью систем, которые они используют.Если у пользователя нет предоставленных разрешений, ему не будет предоставлен доступ. Чтобы сделать его еще более безопасным, вы можете комбинировать использование клиентских сертификатов с паролями. С технической точки зрения это называется «двухфакторной аутентификацией». Это абсолютно необходимо для организаций, имеющих дело с конфиденциальными данными — как внутренними, так и внешними. А знаете, что происходит, если не использовать двухфакторную аутентификацию? Просто спросите Equifax!

Сертификаты клиентов также используют инфраструктуру открытых ключей (PKI) для аутентификации, как и сертификаты серверов.Однако между ними есть одно существенное различие. В отличие от сертификатов сервера, клиентские сертификаты не шифруют никакие данные; они установлены только для проверки.

и сертификат сервера: в чем разница?

Похожие сообщения

Магазин сертификатов веб-серверов

Мы предлагаем самые дешевые SSL-сертификаты от проверенных брендов SSL или центров сертификации.Получите сертификат веб-сервера и сэкономьте до 88%

Покупайте SSL-сертификаты всего за 5,45 долларов США в год

Что такое проверка подлинности сертификата клиента SSL и как она работает?

Знаете ли вы, что SSL может использоваться как для аутентификации клиента, так и для аутентификации сервера? И что такое аутентификация SSL-сертификата клиента для начала?

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

SSL / TLS может намного больше. Его также можно использовать для аутентификации клиента (то есть веб-браузера вашего посетителя) при условии, что у него есть собственный сертификат.

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

Аутентификация уровня защищенных сокетов (SSL) — это протокол для установления защищенного канала связи между клиентом и сервером. Аутентификация SSL защищает связь, шифруя ее во время передачи.Последняя версия протокола аутентификации SSL — TLS1.2.

Проверка подлинности SSL

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

Купите сертификат UCC SSL и сэкономьте до 89%

Мы предлагаем лучшую скидку на все типы SSL-сертификатов UCC.Наши предложения включают сертификаты Comodo UCC или SSL для унифицированных коммуникаций, стоимость которых начинается всего от 18,02 доллара в год.

Магазин сертификатов UCC SSL

Проверка подлинности сертификата сервера SSL и проверка подлинности сертификата клиента SSL

Как мы только что упоминали, перед установкой безопасного соединения необходимо выполнить квитирование SSL / TLS для обработки аутентификации и согласования версии протокола и шифров, которые будут использоваться после начала соединения. Обычно, когда приходит клиент и сервер представляет свой сертификат, функции аутентификации выполняет именно клиент.

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

• Trusted (цифровая подпись),
• Действителен (отметка времени, даты не до / после),
• Не отозван (OCSP или CRL) и
• Правильно зарегистрировано (журналы CT).

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

Преимущества аутентификации с использованием клиентских сертификатов HTTPS

Преимущество использования SSL-аутентификации по сертификату клиента заключается в том, что теперь двухфакторная аутентификация (2FA) может выполняться без кода SMS или отправки электронного письма. Клиентский SSL-сертификат устанавливается на любое устройство, которое предназначено для подключения к данному веб-сайту или серверу, когда пользователь переходит на эту конечную точку, аутентификация их клиентского SSL-сертификата служит частью двухфакторной аутентификации. , позволяя пользователю просто ввести пароль и продолжить свой путь.

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

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

Магазин сертификатов веб-серверов

Мы предлагаем самые дешевые SSL-сертификаты от проверенных брендов SSL или центров сертификации (CA).Получите сертификат веб-сервера и сэкономьте до 88% в зависимости от выбранного сертификата и бренда.

Купить SSL-сертификаты Sectigo всего за $ 5,45

SSL: сертификат клиента против сертификата сервера

Как сертификаты клиента и сервера используются для аутентификации

По состоянию на 2018 год большинство владельцев веб-сайтов хорошо осведомлены о серверных SSL-сертификатах. Клиентские SSL-сертификаты? Не так много. И это досадно, потому что клиентские SSL-сертификаты могут играть важную функцию безопасности для крупных организаций — при условии, что они знают, как их эффективно развернуть.В чем разница между сертификатом клиента и сертификатом сервера и как каждый из них используется? Давай проверим.

Сравнение использования сертификата аутентификации сервера и аутентификации клиента Сертификат

В этой статье мы дадим обзор двух разных типов SSL-сертификатов и их предполагаемых вариантов использования. В первых двух разделах будет рассмотрен вопрос «Что такое сертификат клиента или сертификат сервера?» прежде чем перейти к рассмотрению примеров использования клиентских SSL-сертификатов и способов их аутентификации.

Что такое серверный SSL-сертификат?

В 99% случаев, когда вы слышите, что кто-то упоминает SSL / TLS сертификат, они имеют в виду вариант сервера. Эти сертификаты выполнить две задачи:

1. Они аутентифицируют объект, которому они были выданы, и
2. Они обеспечивают безопасное соединение HTTPS.

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

SSL-сертификаты для одного домена — экономия до 85%!

Совет. Как правило, вы можете сэкономить значительную сумму, купив сертификат SSL напрямую, а не через хостинговую компанию. Мы продаем все SSL-сертификаты Comodo для одного домена со скидкой до 85%.

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

Что такое клиентский SSL-сертификат?

Сертификат клиента — это цифровой сертификат, используемый человеком / устройством для аутентификации своей личности на удаленном сервере при выполнении онлайн-запроса. Сервер может полагаться на сертификат клиента для установления доверия перед ответом на запрос.

Запомните все, что мы только что обсудили с шифрованием и обмен ключами сеанса? Да, забудь об этом сейчас. Клиентские SSL-сертификаты выдается полностью для аутентификации стороны, которой они принадлежат. Они чаще всего развертываются на устройствах Интернета вещей (IoT), поэтому их иногда называют сертификатами Интернета вещей, но их также можно использовать с смартфоны, планшеты, ноутбуки — что угодно. Все, что связано с Интернет.

Положительный SSL — лучший базовый сертификат SSL

Если вы ищете базовый сертификат SSL, который обеспечивает надежное шифрование для вашего веб-сайта, лучше всего подойдет Comodo Positive SSL.
Купите положительный SSL — скидку 84%

Каков вариант использования клиентских SSL-сертификатов?

Простой ответ? Двухфакторная аутентификация. Два фактора аутентификация (2FA) требует двух из трех следующих вещей: есть, что-то, что вы знаете, или что-то, что вы есть. Пароль — это то, что вы знаете. Обычно то, что у вас есть, подтверждается кодом SMS-сообщения или переходом по ссылке. в электронном письме.

Клиентский SSL-сертификат обрабатывает «то, что у вас есть» требование, просто находясь на устройстве.Когда вы используете SSL / TLS для двухфакторная аутентификация, устройство, к которому вы подключаетесь, аутентифицировано в начале подключения — при вводе пароля. Если либо сбой, соединение не работает. В противном случае следует зашифрованное соединение.

Это особенно полезно в крупных корпоративных средах. где платят за физические генераторы случайных чисел (ГСЧ) или другие механизм непомерно дорог. Вместо этого вы можете автоматизировать свой сертификат платформа управления для выдачи сертификатов нового устройства любому устройству, которое доступ к сети.Оттуда каждый раз, когда сотрудник пытается получить доступ к закрытым порциям сети, их сертификат будет аутентифицирован перед установкой связь.

Как проходит аутентификация клиентского SSL-сертификата?

Каждый раз, когда в соединении задействован сертификат SSL / TLS, следует рукопожатие. Во время рукопожатия клиент исследует сертификат и подтвердить его действительность. Это делается путем проверки подпись, следование цепочке сертификатов и проверка журналов CT и отзыва списки.Если все это проверено, сертификату доверяют.

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

При достижении взаимной аутентификации соединение продолжается не ослабевая.

— это быстрый и доступный способ обработки двухфакторная аутентификация без каких-либо затрат на оборудование.

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

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

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

На защищенном HTTP-сайте слева в браузере отображается значок замка. Вы можете дополнительно подтвердить действительность лицензии SSL, щелкнув символ замка.

В современном мире онлайн-бизнес / торговля стали очень популярными среди онлайн-населения из-за простоты покупки и продажи товаров, сидя у себя дома.Вам не нужно выезжать за покупками; вместо этого вы можете использовать свои банковские счета и дебетовые / кредитные карты для покупок в Интернете. Но с этой легкостью существует также угроза кибератак для онлайн-пользователей, которая постоянно растет.

Киберпреступники используют различные уловки для кражи ресурсов веб-сайтов или конфиденциальной информации клиентов, такой как данные кредитной карты, имена пользователей, пароли и т. Д. Затем они используют эти данные для кражи денег с банковского счета цели или для выполнения любых других вредоносных действий для своих выгода.Чтобы обезопасить вас от этих угроз, используются сертификаты клиентов и серверы. Эти сертификаты гарантируют, что обмен информацией между браузером и веб-сайтом закодирован и недоступен для хакеров.

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

Что такое сертификат сервера

Сертификат сервера обычно известен как сертификат SSL / TLS, который подтверждает подлинность веб-сайта. При установке на сервере сертификат уровня защищенных сокетов (SSL) изменяет протокол безопасности с HTTP на HTTPS. Это приводит к отображению в веб-браузере индикаторов (например, значка замка в браузере) для проверки действительности сайта. Это делается для того, чтобы гарантировать клиентам подлинность веб-сайта.

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

Что такое сертификат клиента

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

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

Могут быть некоторые файлы или документы, к которым вы хотите получить доступ только для нескольких выбранных сторон.Как вы знаете, пароли не подходят для этой работы, поэтому вам следует искать другие методы для выполнения этой работы. И здесь на помощь приходят клиентские сертификаты. Клиентские сертификаты проверяют личность пользователей системой, которую они используют, вместо проверки с помощью паролей, предоставленных пользователем. Если у клиента нет авторизованных разрешений, ему не будет предоставлен доступ к документу или файлу. Вы можете комбинировать использование паролей с клиентскими сертификатами, чтобы добавить еще один уровень безопасности. Это станет двухэтапным процессом проверки, также называемым «двухфакторной аутентификацией (2fa)».Двухфакторная аутентификация делает ваши ценные документы более безопасными и является обязательной для организаций, которые имеют дело с конфиденциальными данными своих сотрудников или клиентов.

Сертификаты клиентов не шифруют и не расшифровывают какие-либо данные, в отличие от сертификатов серверов, которые кодируют и декодируют информацию, совместно используемую пользователем и веб-сервером. Однако одно сходство между двумя сертификатами заключается в том, что оба используют инфраструктуру открытого ключа (PKI) для проверки.

и сертификат сервера — разница

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

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

Основные различия между сертификатами сервера и сертификатами клиента описаны ниже:

1. Идентификационный номер

Сертификат сервера используется для подтверждения подлинности сервера перед пользователем. Напротив, сертификат клиента используется для подтверждения действительности клиента на сервере.

2. Шифрование или дешифрование

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

Однако клиентские сертификаты не выполняют шифрование / дешифрование данных.

Идентификатор объекта (OID) для проверки сертификата сервера — 1.3.6.1.5.5.7.3.1, а OID для проверки сертификата клиента — 1.3.6.1.5.5.7.3.2.

Вы также можете проверить это сами, нажав «Просмотреть сертификат». Затем на вкладке сведений нажмите «Расширенное использование ключа», чтобы найти идентификатор вашего сертификата.

Примером сертификата клиента является сертификат клиента электронной почты, тогда как сертификаты SSL являются примером сертификатов сервера.

Сходство между сертификатами сервера и сертификатами клиента

Оба сертификата имеют две общие черты:

1.Сертификаты клиента и сервера основаны на инфраструктуре открытых ключей (PKI).

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

Заключение

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

Связанное сообщение:

Аутентификация с использованием клиентских сертификатов HTTPS | автор: Андрас Шевчик-Заяч

Этот пост был первоначально опубликован в моем блоге .

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

Существует множество способов смягчить это, например, HMAC или временные одноразовые пароли или недавно появившиеся универсальные аппаратные токены 2-фактора.Все они основаны на том, что у пользователя есть , а не на том, что знает . У есть секретный ключ, который они могут использовать для генерации пароля или подписи сообщений.

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

В этом посте мы реализуем простой пример Node.js, который использует клиентские сертификаты для аутентификации пользователя.

Нам нужна только одна внешняя зависимость, express , в противном случае мы просто зависим от стандартного HTTPS-сервера Node.js. Также нам понадобится fs для чтения сертификатов / ключей для настройки HTTPS.

 const express = require ('express') 
 const fs = require ('fs') 
 const https = require ('https') 

Прежде всего, нам нужно сгенерировать наши ключи и сертификаты.Мы используем инструмент командной строки openssl . В Linux он, скорее всего, уже установлен. Если нет, установите пакет openssl вашего дистрибутива. В Windows это немного сложнее, см. Этот учебник;

Как и для любого обычного HTTPS-сервера, нам необходимо сгенерировать сертификат сервера. Для краткости здесь мы используем самозаверяющий сертификат — в реальной жизни вы, вероятно, захотите использовать известный центр сертификации, такой как Let’s Encrypt.

Для создания самоподписанного сертификата (в нашем случае без шифрования):

 $ openssl req -x509 -newkey rsa: 4096 -keyout server_key.pem -out server_cert.pem -nodes -days 365 -subj "/ CN = localhost / O = Client \ Certificate \ Demo" 

Фактически это трехэтапный процесс, объединенный в одну команду:

• Создайте новый 4096-битный RSA key и сохраните его в server_key.pem , без шифрования DES ( -newkey , -keyout и -nodes )
• Создайте запрос на подпись сертификата для данной темы, действительный в течение 365 дней ( -days , -subj )
• Подпишите CSR, используя ключ сервера, и сохраните его в server_cert.pem как сертификат X.509 ( -x509 , -out )

Мы также могли бы сделать это с помощью древовидных команд, openssl genrsa , openssl req и openssl x509 . Мы использовали формат PEM (настройка по умолчанию), который представляет собой текстовый файл в кодировке base64 с заголовком и нижним колонтитулом ----- BEGIN / END CERTIFICATE / PRIVATE KEY ----- . Другой вариант — формат DER, в котором используется двоичное кодирование. Существует некоторая путаница в том, что должно означать расширение файла: также часто используется .key или .crt , ссылаясь на содержимое файла, а не на кодировку (в этом случае они могут содержать данные в кодировке DER и PEM).

Давайте добавим наш ключ сервера и сертификат к объекту options , который мы передадим на сервер HTTPS позже:

 const opts = {key: fs.readFileSync ('server_key.pem') 
, cert: fs.readFileSync ('server_cert.pem') 

Затем мы инструктируем HTTPS-сервер запрашивать сертификат клиента у пользователя

, requestCert: true 

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

, rejectUnauthorized: false 

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

, ca: [fs.readFileSync ('server_cert.pem ')] 
} 

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

 const app = express () 

Сначала мы добавляем нашу «целевую страницу». Это незащищено, поэтому все увидят, предоставят ли они сертификат клиента или нет.

 app.get ('/', (req, res) => {
 res.send (' Войти, используя сертификат клиента ') 
}) 

Затем мы добавляем нашу защищенную конечную точку: она просто отображает информацию о пользователе и срок действия его сертификата.Мы можем получить информацию о сертификате из дескриптора HTTPS-соединения:

 app.get ('/ Authenticate', (req, res) => {
 const cert = req.connection.getPeerCertificate () 

Req.client . авторизованный флаг будет истинным, если сертификат действителен и был выдан центром сертификации, который мы занесли в белый список ранее в opts.ca . Мы отображаем имя нашего пользователя (CN = Common Name) и имя эмитента, который это localhost .

, если (req.client.authorized) {
 res.send (`Здравствуйте, $ {cert.subject.CN}, ваш сертификат был выдан $ {cert.issuer.CN}!`) 

Они все еще могут предоставить сертификат, который мы не принимаем. К сожалению, объект cert будет пустым объектом вместо null , если сертификата нет вообще, поэтому мы должны проверять известное поле, а не истинность.

} else if (cert.subject) {
 res.status (403) 
 .send (`Извините, $ {cert.subject.CN}, сертификаты от $ {cert.issuer.CN} здесь не приветствуются.`) 

И, наконец, они могут прийти к нам вообще без сертификата:

} else {
 res.status (401) 
 .send (` Извините, но вам нужно предоставить сертификат клиента, чтобы продолжить. ') 
} 
}) 

Давайте создадим наш HTTPS-сервер, и мы готовы к работе.

 https.createServer (opts, app) .listen (9999) 

Затем мы можем запустить наш сервер с npm i && node server.js .

Если мы попытаемся «войти» на наш сайт сейчас, мы получим ответ 401 , потому что у нас еще нет клиентских сертификатов.Чтобы протестировать нашу настройку, мы создаем два сертификата для наших двух пользователей, Алисы и Боба. Алиса хороша тем, что у нее есть действующий сертификат, выданный нами, в то время как Боб мерзок и пытается войти в систему, используя самоподписанный сертификат.

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

 $ openssl req -newkey rsa: 4096 -keyout alice_key.pem -out alice_csr.pem -nodes -days 365 -subj " / CN = Алиса "
 $ openssl req -newkey rsa: 4096 -keyout bob_key.pem -out bob_csr.pem -nodes -days 365 -subj "/ CN = Bob" 

Мы подписываем CSR Алисы нашим ключом и сохраняем его как сертификат. Здесь мы выступаем в качестве центра сертификации, поэтому мы предоставляем наш сертификат и ключ через параметры -CA :

 $ openssl x509 -req -in alice_csr.pem -CA server_cert.pem -CAkey server_key.pem -out alice_cert. pem -set_serial 01 -days 365 

Боб не верит в авторитет, поэтому он просто подписывает свой сертификат самостоятельно:

 $ openssl x509 -req -in bob_csr.pem -signkey bob_key.pem -out bob_cert.pem -days 365 

Чтобы использовать эти сертификаты в нашем браузере, нам нужно объединить их в формате PKCS # 12. Он будет содержать как закрытый ключ, так и сертификат, поэтому браузер может использовать его для шифрования. Для Алисы мы добавляем опцию -clcerts , которая исключает сертификат CA из пакета. Поскольку мы выпустили сертификат, у нас уже есть сертификат: нам не нужно включать его в сертификат Алисы. Вы также можете защитить сертификат паролем.

 $ openssl pkcs12 -export -clcerts -in alice_cert.pem -inkey alice_key.pem -out alice.p12 
 $ openssl pkcs12 -export -in bob_cert.pem -inkey bob_key.pem -out bob.p12 

Мы можем импортировать эти закрытые ключи к браузеру. В Firefox перейдите в «Настройки » -> «Дополнительно» -> «Просмотр сертификатов» -> «Импортировать » и выберите оба файла.

Если вы сейчас откроете https: // localhost: 9999 в браузере, появится диалоговое окно для выбора сертификата. Обратите внимание, что в списке присутствует только сертификат Алисы: это потому, что браузер уже знает, что будут приняты только сертификаты, выданные нами (потому что мы рекламируем его с помощью опций .около список). Если вы продолжите, вы увидите сообщение об успешном выполнении с подробной информацией об Алисе.

Это только ограничение браузера, вы все равно можете попытаться войти с сертификатом Боба, используя cURL:

 $ curl --insecure --cert bob.p12 --cert-type p12 https: // localhost: 9999 / Authenticate 

И посмотрите, Бобу здесь не рады!

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

Чтобы попробовать этот сервер, клонируйте репозиторий github этого поста, где вы также можете найти ключи и сертификаты.

Аутентификация клиента | Разгрузка и ускорение SSL

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

Примечание. Начиная с выпуска 13.0 build 41.x, устройство Citrix ADC поддерживает сообщения запроса сертификата, которые фрагментированы на несколько записей при условии, что общий размер не превышает 32 КБ. Ранее максимальный поддерживаемый размер составлял 16 КБ, и фрагментация не поддерживалась.

Если на виртуальном сервере SSL включена проверка подлинности клиента, устройство Citrix ADC запрашивает сертификат клиента во время установления связи SSL.Устройство проверяет сертификат, представленный клиентом, на предмет обычных ограничений, таких как подпись издателя и срок действия.

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

Если сертификат действителен, устройство разрешает клиенту доступ ко всем защищенным ресурсам. Но если сертификат недействителен, устройство отбрасывает клиентский запрос во время установления связи SSL.

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

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

Примечание. Устройство Citrix ADC MPX поддерживает размер пары ключ-сертификат от 512 до 4096 бит. Сертификат должен быть подписан с использованием одного из следующих алгоритмов хеширования:

• MD5
• SHA-1
• SHA-224
• SHA-256
• SHA-384
• SHA-512

На устройстве SDX, если микросхема SSL назначена экземпляру VPX, применяется поддержка размера пары сертификат-ключ устройства MPX.В противном случае применяется стандартная поддержка размера пары сертификат-ключ экземпляра VPX.

Виртуальное устройство Citrix ADC (экземпляр VPX) поддерживает сертификаты не менее 512 бит, вплоть до следующих размеров:

• 4096-битный сертификат сервера на виртуальном сервере
• 4096-битный сертификат клиента на сервисе
• 4096-битный сертификат CA
• 4096-битный сертификат на физическом сервере

Примечание: Начиная с версии 13.0 build 79.x, аутентификация клиента с помощью 4096-битного сертификата клиента RSA поддерживается во время установления связи SSL на платформе VPX.

Примечания:

Предоставляем клиентский сертификат

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

Независимо от того, получаете ли вы сертификат клиента из центра сертификации, используете существующий сертификат клиента или генерируете сертификат клиента на устройстве Citrix ADC, вы должны преобразовать сертификат в правильный формат. На устройстве Citrix ADC сертификаты хранятся в формате PEM или DER и должны быть преобразованы в формат PKCS # 12 перед установкой в ​​клиентской системе. После преобразования сертификата и передачи его в клиентскую систему убедитесь, что он установлен в этой системе и настроен для клиентского приложения.Приложение, такое как веб-браузер, должно быть частью транзакций SSL.

Инструкции по преобразованию сертификата из формата PEM или DER в формат PKCS # 12 см. В разделе Импорт и преобразование файлов SSL.

Инструкции по созданию сертификата клиента см. В разделе Создание сертификата.

Включить аутентификацию на основе сертификата клиента

По умолчанию аутентификация клиента отключена на устройстве Citrix ADC, и все транзакции SSL продолжаются без аутентификации клиента.Вы можете настроить аутентификацию клиента как необязательную или обязательную как часть подтверждения SSL.

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

Внимание! Citrix рекомендует определить правильные политики управления доступом перед изменением проверки подлинности на основе сертификата клиента на необязательную.

Примечание. Проверка подлинности клиента настроена для отдельных виртуальных серверов SSL, а не глобально.

Включить проверку подлинности на основе сертификата клиента с помощью интерфейса командной строки

В командной строке введите следующие команды, чтобы включить аутентификацию на основе сертификата клиента и проверить конфигурацию:

  set ssl vserver  [-clientAuth (ВКЛЮЧЕНО | ОТКЛЮЧЕНО)] [-clientCert (ОБЯЗАТЕЛЬНО | ДОПОЛНИТЕЛЬНО)]
показать ssl vserver 

  

Пример:

  set ssl vserver vssl -clientAuth ENABLED -clientCert Обязательно
Выполнено
показать ssl vserver vssl

Расширенная конфигурация SSL для VServer vssl:
DH: ОТКЛЮЧЕНО
Эфемерный RSA: ВКЛЮЧЕНО Количество обновлений: 0
Повторное использование сеанса: ВКЛЮЧЕНО Тайм-аут: 120 секунд
Перенаправление шифра: ОТКЛЮЧЕНО
Перенаправление SSLv2: ОТКЛЮЧЕНО
Порт ClearText: 0
Проверка подлинности клиента: ВКЛЮЧЕНО Требуется сертификат клиента: обязательно
Перенаправление SSL: ОТКЛЮЧЕНО
Шифры, отличные от FIPS: ОТКЛЮЧЕНО
        SNI: ОТКЛЮЧЕНО
        OCSP Stapling: ОТКЛЮЧЕНО
        HSTS: ОТКЛЮЧЕНО
        HSTS IncludeSubDomains: НЕТ
        HSTS Макс. Возраст: 0
SSLv2: ОТКЛЮЧЕН SSLv3: ВКЛЮЧЕН TLSv1.0: ВКЛЮЧЕН TLSv1.2: ВКЛЮЧЕН TLSv1.2: ВКЛЮЧЕН

1) Имя CertKey: сертификат сервера sslckey

1) Имя политики: client_cert_policy Priority: 0

1) Имя шифра: ПО УМОЛЧАНИЮ
Описание: предопределенный псевдоним шифра
Выполнено

  

Включить проверку подлинности на основе сертификата клиента с помощью графического интерфейса пользователя

1. Перейдите к Управление трафиком> Балансировка нагрузки> Виртуальные серверы и откройте виртуальный сервер.
2. В разделе «Параметры SSL» выберите «Проверка подлинности клиента» и в списке «Сертификат клиента» выберите «Обязательный».

Примечание:

Если проверка подлинности клиента установлена ​​на обязательную, и если сертификат клиента содержит расширения политики, проверка сертификата не выполняется. Начиная с версии 12.0-56.x, вы можете установить параметр во внешнем профиле SSL, чтобы пропустить эту проверку. По умолчанию параметр отключен. То есть проверка выполняется по умолчанию.

Пропустить проверку расширения политики во время аутентификации клиента с помощью интерфейса командной строки

В командной строке введите:

  установить профиль ssl ns_default_ssl_profile_frontend -clientauth ВКЛЮЧЕНО -skipClientCertPolicyCheck ВКЛЮЧЕНО

Параметр

skipClientCertPolicyCheck

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

- ВКЛЮЧЕНО: пропустить проверку политики во время аутентификации клиента.

- ОТКЛЮЧЕНО: выполнять проверку политики во время аутентификации клиента.

Возможные значения: ENABLED, DISABLED.

По умолчанию: ОТКЛЮЧЕНО

  

Пропустить проверку расширения политики во время аутентификации клиента с помощью графического интерфейса пользователя

1. Перейдите к System > Profiles > SSL Profiles .
2. Создайте новый интерфейсный профиль или отредактируйте существующий интерфейсный профиль.
3. Убедитесь, что проверка подлинности клиента включена и сертификат клиента установлен как обязательный.
4. Выберите Пропустить проверку политики сертификата клиента .

Привязать сертификаты ЦС к виртуальному серверу

ЦС, сертификат которого присутствует на устройстве Citrix ADC, должен выдать сертификат клиента, используемый для аутентификации клиента. Привяжите этот сертификат к виртуальному серверу Citrix ADC, который выполняет аутентификацию клиента.

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

Вы можете привязать сертификаты CA к виртуальному серверу SSL в любом порядке. Устройство формирует правильный порядок во время проверки сертификата клиента.

Например, если клиент представляет сертификат, выданный CA_A , где CA_A является промежуточным ЦС, сертификат которого выдается CA_B , чей сертификат, в свою очередь, выдается доверенным корневым ЦС, Root_CA , a цепочка сертификатов, содержащих все три сертификата, должна быть привязана к виртуальному серверу на устройстве Citrix ADC.

Инструкции по привязке одного или нескольких сертификатов к виртуальному серверу см. В разделе Привязка пары ключ-сертификат к виртуальному серверу SSL.

Инструкции по созданию цепочки сертификатов см. В разделе Создание цепочки сертификатов.

Более строгий контроль за проверкой сертификата клиента

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

Однако, если клиент отправляет цепочку сертификатов в рукопожатии, ни один из промежуточных сертификатов не может быть проверен с помощью ответчика CRL или OCSP, если этот сертификат не привязан к виртуальному серверу SSL. Следовательно, даже если один из промежуточных сертификатов отозван, рукопожатие будет успешным. В рамках рукопожатия виртуальный сервер SSL отправляет список привязанных к нему сертификатов ЦС. Для более строгого контроля вы можете настроить виртуальный сервер SSL на прием только сертификата, подписанного одним из сертификатов CA, привязанных к этому виртуальному серверу.Для этого необходимо включить параметр ClientAuthUseBoundCAChain в профиле SSL, привязанном к виртуальному серверу. Рукопожатие не удается, если один из сертификатов CA, привязанных к виртуальному серверу, не подписал сертификат клиента.

Например, скажем, два клиентских сертификата, clientcert1 и clientcert2, подписаны промежуточными сертификатами Int-CA-A и Int-CA-B соответственно. Промежуточные сертификаты подписываются корневым сертификатом Root-CA. Int-CA-A и Root-CA привязаны к виртуальному серверу SSL.В случае по умолчанию (ClientAuthUseBoundCAChain отключен) принимаются как clientcert1, так и clientcert2. Однако, если ClientAuthUseBoundCAChain включен, устройство Citrix ADC принимает только clientcert1.

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

В командной строке введите:

  установить профиль ssl <имя> -ClientAuthUseBoundCAChain Enabled

  

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

1. Перейдите к System > Profiles , выберите вкладку SSL Profiles и создайте профиль SSL или выберите существующий профиль.
2. Выберите Включить аутентификацию клиента с использованием связанной цепочки CA .

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

DIESER DIENST KANN ÜBERSETZUNGEN ENTHALTEN, DIE VON GOOGLE BEREITGESTELLT WERDEN. GOOGLE LEHNT Jede AUSDRÜCKLICHE ОДЕР STILLSCHWEIGENDE GEWÄHRLEISTUNG В BEZUG АУФ DIE Übersetzungen AB, EINSCHLIESSLICH JEGLICHER GEWÄHRLEISTUNG МЭД GENAUIGKEIT, Zuverlässigkeit UND JEGLICHER STILLSCHWEIGENDEN GEWÄHRLEISTUNG МЭД MARKTGÄNGIGKEIT, МЭД EIGNUNG FÜR Einen BESTIMMTEN Zweck UND DER NICHTVERLETZUNG VON RECHTEN DRITTER.

CE SERVICE PEUT CONTENIR DES TRADUCTIONS FOURNIES PAR GOOGLE. GOOGLE EXCLUT TOUTE GARANTIE RELATIVE AUX TRADUCTIONS, EXPRESSE OU IMPLICITE, Y COMPRIS TOUTE GARANTIE D’EXACTITUDE, DE FIABILITÉ ET TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE, D’ADÉQUATION D’REULER UN US.

ESTE SERVICIO PUEDE CONTENER TRADUCCIONES CON TECNOLOGA DE GOOGLE. GOOGLE RENUNCIA A TODAS LAS GARANTÍAS RELACIONADAS CON LAS TRADUCCIONES, TANTO IMPLÍCITAS COMO EXPLÍCITAS, INCLUIDAS LAS GARANTÍAS DE EXACTITUDONE, FIABILIDAD Y OTRAS GARANTÍAS PARTUS INPLCITAS DEERADIC UNDERIABIL EN

本 服务 可能 包含 Google 提供 技术 支持 的 翻译 。Google 对 这些 翻译 内容 不做 明示 暗示 的 保证 ， 包括 对 准确性 、 可靠性 的 任何 以及 适销 性 和 非 性的 任何 暗示 保证。

こ の サ ー ビ ス に は, Google が 提供 す る 翻 訳 が 含 ま れ て い る 可能性 が あ り ま す .Google は 翻 訳 に つ い て, 明示 的 か 黙 示 的 か を 問 わ ず, 精度 と 信 頼 性 に 関 す る あ ら ゆ る 保証, お よ び 商品性, 特定 目的 への 適合 性 、 第三者 の 権 利 を な い こ と に 関 す る あ 的 保証 を 含 め 、 ま せ ん。

ESTE SERVIO PODE CONTER TRADUÇÕES FORNECIDAS PELO GOOGLE. О GOOGLE SE EXIME DE TODAS AS GARANTIAS RELACIONADAS COM AS TRADUES, EXPRESSAS OU IMPLÍCITAS, INCLUINDO QUALQUER GARANTIA DE PRECISÃO, CONFIABILIDADE E QUALQUER GARANTIA IMPLÍCITA DE COMERCIALIZAO, ADERAITA DE COMERCIALIZAO.