Outlook + Postfix (tls/ssl)
Установить в систему сертификат сервера или CA, которым он подписан?
А лучше установить нормальный почтовый клиент.
Deleted
( 01.06.11 09:13:49 MSK )
у тебя самоподписанный сертификат что ли?
visual_pipe
( 01.06.11 09:14:12 MSK )
Ответ на: комментарий от visual_pipe 01.06.11 09:14:12 MSK
drac753 ★★
( 01.06.11 09:31:07 MSK ) автор топика
Ответ на: комментарий от Deleted 01.06.11 09:13:49 MSK
какой можете порекомендовать , желательно бесплатный ?
drac753 ★★
( 01.06.11 09:56:50 MSK ) автор топика
Ответ на: комментарий от drac753 01.06.11 09:56:50 MSK
Да тот же Thunderbird.
Deleted
( 01.06.11 10:02:26 MSK )
Ответ на: комментарий от Deleted 01.06.11 10:02:26 MSK
Ок щас почищу птичке пёрышки
drac753 ★★
( 01.06.11 10:07:47 MSK ) автор топика
Ответ на: комментарий от drac753 01.06.11 09:31:07 MSK
1) Добавить свой сертификат в список доверенных на клиенте (дабл-клик на your_cert.crt)
2) Купить сертификат подписанный CA которые уже есть в винде. Например verisign и т.п.
zgen ★★★★★
( 01.06.11 10:08:10 MSK )
Ответ на: комментарий от Deleted 01.06.11 09:13:49 MSK
А лучше установить нормальный почтовый клиент.
А чем «нормальный» почтовый клиент поможет в случае, когда используется self-signed cert?
ps. сам пользуюсь tb
zgen ★★★★★
( 01.06.11 10:08:59 MSK )
Ответ на: комментарий от zgen 01.06.11 10:08:59 MSK
Вопрос по птичке , я тут заметил что в на сервере в каталоге с почтовым ящиком она создаёт два каталога /.Trash и /.Send , для чего ?
drac753 ★★
( 01.06.11 10:24:54 MSK ) автор топика
Ответ на: комментарий от drac753 01.06.11 10:24:54 MSK
Очевидно для того, чтобы складывать на сервер мусор и отправленные.
Или у вас словаря для перевода нет?
zgen ★★★★★
( 01.06.11 10:30:53 MSK )
Ответ на: комментарий от zgen 01.06.11 10:30:53 MSK
есть, с этим разобрался
drac753 ★★
( 01.06.11 10:32:44 MSK ) автор топика
Ответ на: комментарий от drac753 01.06.11 10:32:44 MSK
Возникла не большая проблема , при создании я ящика в параметрах сервера , задаю имя пароль ssl/tls , в Сервер исходящей почты — ip сервака , порт по у молчанию 25 , когда пытаюсь выставить защиту соединения ssl/tls он автоматом меняется на 465 так и должно быть ?
drac753 ★★
( 01.06.11 10:46:46 MSK ) автор топика
Ответ на: комментарий от drac753 01.06.11 10:46:46 MSK
естественно, т.к. tls использует 465-й порт, ssl — 587 или 465
cac2s ★
( 01.06.11 11:00:00 MSK )
Ответ на: комментарий от cac2s 01.06.11 11:00:00 MSK
странно если в Сервер исходящей почты не ставить ssl\tls почта приходит и уходит, а если поставить то вылазиет —
Ошибка отправления сообщения. Сообщение не может быть отправлено, так как время ожидания соединения с SMTP-сервером «192.168.4.25» истекло. Попробуйте снова или свяжитесь с администратором сети.
шифрование вроде настроено, 465 порт на фаере открыт
iptables -A INPUT -i eth0 -p tcp -m multiport --dport 25,80,22,110,143,995,993,465 -j ACCEPT # TLS parameters #### подгоняем этот участок к такому виду - начало smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:$/smtpd_scache smtp_tls_session_cache_database = btree:$/smtp_scache smtpd_sasl_type=dovecot smtpd_sasl_path=private/auth smtpd_recipient_restrictions=permit_mynetworks,per mit_sasl_a uthenticated,reject_unauth_destination smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem smtpd_tls_key_file=/etc/ssl/private/postfix.pem ### конец где может быть косяк ?
drac753 ★★
( 01.06.11 11:13:30 MSK ) автор топика
Ответ на: комментарий от drac753 01.06.11 11:13:30 MSK
в master.cf есть что-то наподобие таких строчек:
smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATINGcac2s ★
( 01.06.11 11:51:39 MSK )
Ответ на: комментарий от cac2s 01.06.11 11:51:39 MSK
# # Postfix master process configuration file. For details on the format # of the file, see the master(5) manual page (command: "man 5 master"). # # Do not forget to execute "postfix reload" after editing this file. # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - - - - smtpd #submission inet n - - - - smtpd # -o smtpd_tls_security_level=encrypt # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING #628 inet n - - - - qmqpd pickup fifo n - - 60 1 pickup cleanup unix n - - - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - - 300 1 oqmgr tlsmgr unix - - - 1000? 1 tlsmgr rewrite unix - - - - - trivial-rewrite bounce unix - - - - 0 bounce defer unix - - - - 0 bounce trace unix - - - - 0 bounce verify unix - - - - 1 verify flush unix n - - 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - - - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - - - - smtp -o smtp_fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - - - - showq error unix - - - - - error retry unix - - - - - error discard unix - - - - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - - - - lmtp anvil unix - - - - 1 anvil scache unix - - - - 1 scache # # ==================================================================== # Interfaces to non-Postfix software. Be sure to examine the manual # pages of the non-Postfix software to find out what options it wants. # # Many of the following services use the Postfix pipe(8) delivery # agent. See the pipe(8) man page for information about $ # and other message envelope options. # ==================================================================== # # maildrop. See the Postfix MAILDROP_README file for details. # Also specify in main.cf: maildrop_destination_recipient_limit=1 # maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d $ # # ==================================================================== # # Recent Cyrus versions can use the existing "lmtp" master.cf entry. # # Specify in cyrus.conf: # lmtp cmd="lmtpd -a" listen="localhost:lmtp" proto=tcp4 # # Specify in main.cf one or more of the following: # mailbox_transport = lmtp:inet:localhost # virtual_transport = lmtp:inet:localhost # # ==================================================================== # # Cyrus 2.1.5 (Amos Gouaux) # Also specify in main.cf: cyrus_destination_recipient_limit=1 # #cyrus unix - n n - - pipe # user=cyrus argv=/cyrus/bin/deliver -e -r $ -m $ $ # # ==================================================================== # Old example of delivery via Cyrus. # #old-cyrus unix - n n - - pipe # flags=R user=cyrus argv=/cyrus/bin/deliver -e -m $ $ # # ==================================================================== # # See the Postfix UUCP_README file for configuration details. # uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) # # Other external delivery methods. # ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient scalemail-backend unix - n n - 2 pipe flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store $ $ $ mailman unix - n n - - pipe flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py $ $ dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d $
Но почта не отправляется в логах
Jun 1 12:48:29 posts postfix/smtpd[31393]: warning: TLS library problem: 31393:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1102:SSL alert number 46: Jun 1 12:48:29 posts postfix/smtpd[31393]: connect from unknown[192.168.4.15] Jun 1 12:48:29 posts postfix/smtpd[31393]: SSL_accept error from unknown[192.168.4.15]: 0 Jun 1 12:48:29 posts postfix/smtpd[31393]: warning: TLS library problem: 31393:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1102:SSL alert number 46: Jun 1 12:48:29 posts postfix/smtpd[31393]: lost connection after CONNECT from unknown[192.168.4.15] Jun 1 12:48:29 posts postfix/smtpd[31393]: disconnect from unknown[192.168.4.15] Jun 1 12:48:50 posts postfix/smtpd[31393]: connect from unknown[192.168.4.15] Jun 1 12:48:52 posts postfix/smtpd[31393]: disconnect from unknown[192.168.4.15] Jun 1 12:48:57 posts postfix/smtpd[31393]: connect from unknown[192.168.4.15] Jun 1 12:50:39 posts postfix/smtpd[31393]: disconnect from unknown[192.168.4.15] Используемый сервер имеет сертификат который невозможно проверить outlook
При старте outllok, постоянно появляется сообщение «Используемый сервер имеет сертификат безопасности, который невозможно проверить» и постоянно надо нажимать ДА чтобы продолжить.
Подскажите как отключить эту проверку?
Добавлял сертификат в доверенные, не помогло.
Проверяется не только сертификат, но и цепочка центров сертификации, от выданного до ближайшего, который находится в доверенных (или может быть проверен, что это так). Вроде что-то типа этого
(1) Как убрать эту проверку? Когда то через реестр это делал, но уже не помню как.
(0) попробуй помести в раздел корневых, и! обязательное условие — имя домена в сертификате должно совпадать с прописаным в учетке аутлука, т.е если в сертификате прописано
mail.local, то и pop-smtp сервер у тебя тоже должен быть прописан, как mail.local. Тогда проблема уйдет. Если не имя не совпадает — то куда бы не добавлял серт — будет ругаться.
Если перевыпуск сертификата недоступен (не товой почтовик), то совпадение имени можно организовать через hosts
Используемый сервер имеет сертификат который невозможно проверить outlook
Протоколы защиты соединений
Существуют различные протоколы защиты соединений, реализующие шифрование на различных уровнях: на сетевом, на транспортном или на прикладном.
Сетевые протоколы — это защита не одного конкретного соединения, а целой сети. Подключение к защищенной сети автоматически предоставляет пользователю доступ ко всей информации, циркулирующей по этой сети. Такой подход удобен, например, для корпоративного взаимодействия (локальная сеть или ее распределенный аналог), но совершенно не подходит для взаимодействия, например, с клиентами. Примеры сетевого протокола — различные протоколы, на основании которых строятся сети VPN: IPSec, PPTP, OpenVPN.
Прикладные протоколы предназначены для решения конкретных специализированных задач и требуют использования соответствующего программного обеспечения, зачастую нестандартного и непривычного для пользователя. Пример прикладного протокола — протокол ssh.
Транспортные протоколы идеально подходят для защиты соединений, предоставляющих доступ к отдельным видам сервисов, предоставляемым сервером. Именно такие клиент-серверные соединения используются в огромном большинстве в интернет-приложениях, если для доступа на сервер требуется аутентификация пользователя, а также если передача информации между сервером и клиентом должна быть закрытой. В настоящее время наиболее распространенным протоколом транспортного уровня в интернет-приложениях является протокол TLS, который является развитием более ранней версии — протокола SSL.
Протокол TLS и протоколы интернет-соединений
TLS-серверы и TLS-клиенты
В качестве TLS-серверов и TLS-клиентов используются различные приложения. Например: сервер Apache и клиент Internet Explorer реализуют протокол https, сервер Dovecot и клиент Outlook реализуют протоколы POP3S и IMAPS, почтовый сервер Postfix является одновременно и клиентом и сервером протокола SMTPS, Outlook также может выступать в качестве клиента SMTPS при отправке сообщений на почтовый сервер.
Криптобиблиотеки, реализующие протокол TLS
Протокол TLS реализуют криптографические динамические библиотеки. В современных ОС Windows этот протокол может быть реализован с помощью Microsoft CryptoAPI. Кроме того, существует ряд Open Source-библиотек, реализующих протокол TLS, среди них библиотеки OpenSSL и GNU TLS. Наиболее распространенной является криптобиблиотека OpenSSL, работающая в большинстве существующих операционных систем.
Продукты, реализующие различные криптографические алгоритмы в TLS
В ООО «Криптоком» разработаны программные продукты, предоставляющие возможность использовать в TLS-соединениях российские криптографические алгоритмы ГОСТ.
Алгоритмы ГОСТ для библиотеки OpenSSL реализованы в подключаемом модуле engine, входящем в состав продукта МагПро КриптоПакет. Криптобиблиотека OpenSSL версии 0.9.8 не предназначена для подключения модуля, содержащего алгоритмы ГОСТ, поэтому МагПро КриптоПакет также включает в себя модифицированную версию библиотеки OpenSSL. Эта версия предоставляет всю функциональность, которую предоставляет библиотека OpenSSL версии 0.9.8, и имеет возможность работать с алгоритмами ГОСТ.
Библиотека OpenSSL версии 0.9.9 может подключать подгружаемый модуль engine, реализующий алгоритмы ГОСТ, поэтому для реализации протокола TLS на алгоритмах ГОСТ с помощью OpenSSL 0.9.9 достаточно только такого модуля.
МагПро КриптоПакет в TLS-соединении может использоваться как на стороне клиента, так и на стороне сервера.
Для реализации алгоритмов ГОСТ в ОС Windows с помощью Microsoft CryptoAPI в ООО > разработан криптопровайдер МагПро CSP. Он также может быть использован при реализации протокола TLS.
Аутентификация сервера
При установлении соединения, защищенного по протоколу TLS, непременно производится аутентификация сервера. Это делается для того, чтобы клиент мог быть уверен, что соединение установлено именно с тем сервером, с которым планируется обмен информацией, а не с каким-либо другим компьютером, выдающим себя за сервер.
Аутентификация сервера всегда является криптографической, т.е. выполняется с помощью сертификата сервера. У сервера обязательно должна быть ключевая пара, и клиент должен иметь возможность проверки подлинности сертификата, который сервер предоставляет ему для аутентификации. (Подробно об аутентификации сервера.)
Аутентификация клиента
Аутентификация клиента в протоколе TLS не является обязательной. Необходимость и способ аутентификации клиента определяется регламентом работы сервера.
Существует достаточно много случаев использования протокола TLS, когда достаточно уверенности клиента в том, что сервер, с которым он соединился, подлинный, и сессия будет защищена.
Аутентификация клиента может быть парольной и криптографической. При этом криптографическая аутентификация клиента является частью протокола TLS, а парольная аутентификация реализуется на прикладном уровне, т.е. средствами приложения.
При принятии решения о том, требовать ли с клиента криптографической аутентификации, следует учитывать, что эта аутентификация достаточно трудоемка и сложна для пользователя. Соответственно, требуется поддержка выдачи и отзыва клиентских сертификатов, пользователь должен соблюдать регламенты работы с долговременной ключевой информацией, поэтому криптографическая аутентификация клиентов применяется достаточно редко — только в таких критических приложениях, как, например, система WebMoney. И даже в таких приложениях, как правило, предусматривается альтернативный способ аутентификации, поскольку некоторые абонентские устройства, например мобильные телефоны, могут не поддерживать клиентские сертификаты.
Поэтому чаще всего используется аутентификация клиента по имени и паролю. В сочетании с криптографической аутентификацией сервера и последующей защитой канала это обеспечивает безопасность, достаточную для работы большинства приложений.
Защита данных
Цель защиты данных при TLS-соединении — сделать так, чтобы никто из тех, кто имеет возможность просматривать поток данных между клиентом и сервером, не мог извлечь из этого потока осмысленную информацию.
Защита данных при TLS-соединении реализуется с помощью шифрования всех передаваемых данных (в обе стороны). Для этого при каждом TLS-соединении вырабатываются специальные ключи для шифрования данных. Эти ключи называются сессионными (сессия — это однократное соединение от установления до разрыва соединения) и после завершения сессии уничтожаются без возможности восстановления.
Сразу после аутентификации сторон (или только сервера) происходит выработка и согласование ключей, которые будут использоваться для шифрования сессионных ключей. Для этого используются ключи сервера и клиента. Если у клиента нет долгосрочной ключевой пары (для соединения с сервером не требуется криптографической аутентификации), программа-клиент вырабатывает эфемерную ключевую пару, которая используется так же, как использовалась бы долгосрочная ключевая пара в этом случае.
Согласование ключей происходит без их передачи по каналу связи, т.к. защита канала еще не установлена.
Следует иметь в виду, что возможно TLS-соединение без защиты данных, только с взаимной аутентификацией или даже только с аутентификацией сервера. Такое соединение имеет смысл при передаче несекретных данных, особенно в больших объемах. При TLS-соединении без защиты данных крайне нежелательно использовать парольную аутентификацию клиента, т.к. в этом случае пароль передается в незашифрованном виде и может быть подсмотрен. Поэтому аутентификация клиента, если она применяется, в таком соединении должна быть криптографической.
При использовании протокола TLS есть возможность пользоваться различными криптографическими алгоритмами и использовать их различными способами. Эта возможность реализуется в виде различных наборов алгоритмов и особенностей протокола, которые можно использовать в TLS-соединениях. При каждом TLS-соединении используется один такой набор, причем он должен быть одинаковым у обеих сторон.
Такие наборы называются шифрсьютами (cipher suites).
У каждого программного продукта, реализующего протокол TLS, имеется некоторый определенный набор шифрсьютов, зависящий как от доступных алгоритмов, так и от собственно реализации протокола.
Такой набор шифрсьютов может быть расширяемым. То есть существует некоторый набор шифрсьютов, подключаемый при запуске приложения, использующего библиотеку OpenSSL, без дополнительных указаний. Этот набор включает не все доступные шифрсьюты. Если необходимы дополнительные шифрсьюты, они должны быть явно указаны в конфигурационном файле OpenSSL, и приложение должно вызывать их через обращение к этому файлу с помощью соответствующей функции (см. документ «Средство криптографической защиты информации МагПро КриптоПакет. Библиотека libssl. Руководство программиста (СЕИУ 00009-01 33 02)»).
В продукте МагПро КриптоПакет могут быть дополнительно подключены шифрсьюты без шифрования и без авторизации (анонимные шифрсьюты — используются в редчайших случаях).
Список доступных шифрсьютов можно получить командой openssl ciphers.
Шифрсьюты, включаемые по умолчанию:
GOST2001-GOST89-GOST89 и GOST94-GOST89-GOST89;
Дополнительные шифрсьюты без шифрования:
В данном случае в названиях шифрсьютов указываются соответственно по порядку: алгоритм выработки подписи и согласования ключей, алгоритм симметричного шифрования данных и алгоритм контроля целостности.
Ниже приводится расшифровка данных обозначений.
Расшифровка обозначений в шифрсьютах МагПро КриптоПакет
с использованием алгоритмов ГОСТ
(Подробно о том, какие шифрсьюты включены в OpenSSL и какие алгоритмы включены в какой шифрсьют, можно узнать из man-руководства к команде ciphers.)
Понятие о хендшейке
«Хендшейк» (рукопожатие) — это фаза (часть) сессии TLS-соединения, во время которой обе стороны «представляются друг другу».
Хендшейк обязательно включает в себя аутентификацию сервера, при необходимости — аутентификацию клиента, согласование и выработку сессионных ключей.
Хендшейк обязательно выполняется в начале сессии TLS-соединения.
При установлении TLS-соединения программа-клиент и программа-сервер в первую очередь обмениваются информацией о доступных шифрсьютах и > о том, какой шифрсьют они будут использовать в данном соединении. Обычно выбор шифрсьюта производится по критерию наибольшей защищенности.
С того момента, как шифрсьют выбран, дальнейший хендшейк зависит от выбранного шифрсьюта. В частности, шифрсьютом определяется способ аутентификации сервера (и клиента).
Можно повторить хендшейк, заново провести аутентификацию и согласовать новые ключи, не прерывая сессии. Эта возможность используется, например, в тех случаях, если в момент начального хендшейка не проводится аутентификация клиента, а потом в ходе сессии становится понятным, что аутентификация клиента требуется, и какая именно аутентификация клиента требуется — парольная или криптографическая.
Поскольку фаза хендшейка достаточно трудоемка, для протокола TLS существует техническая возможность сохранения сессии и последующего ее возобновления. Это особенно актуально для протоколов, которые часто создают и закрывают TCP/IP соединения, например http.
В продукте МагПро КриптоПакет это не реализовано, потому что в нем используется дополнительная защита keymeshing (см. RFC 4357) — сессионные ключи меняются через каждый килобайт переданных данных. Поэтому сохранение сессии (т.е. взаимосогласованных ключей) технически крайне затруднено.
Строение сессии TLS-соединения
Хендшейк. Обмен шифрсьютами. Аутентификация сервера. Если необходимо — аутентификация клиента, выработка и согласование сессионных ключей для защиты данных.
Обмен данными в обе стороны. Данные зашифровываются программой-отправителем на сессионных ключах, передаются, принимаются программой-получателем и расшифровываются. Выполняются проверки целостности данных.
В ходе сессии могут выполняться также повтоные хендшейки.
Аутентификация сервера > цепочек доверия.
Чтобы корневой сертификат удостоверяющего центра был доверенным, необходимо либо получить его по надежному каналу (по какому-либо закрытому каналу связи либо непосредственно в удостоверяющем центре), либо получить по аналогичному надежному каналу его контрольную сумму (т.наз. fingerprint) и при установке сертификата удостоверяющего центра сравнить продемонстрированную контрольную сумму с имеющейся.
Статус сертификата
У каждого сертификата имеется ограниченный срок действия, в сертификате указываются даты начала и конца срока действия. Если текущее время на машине, проверяющей сертификат, не попадает в период между этими датами, сертификат считается некорректным.
Списки отзыва сертификатов
Удостоверяющий центр может отозвать сертификат. Отзыв сертификата производится, например, если скомпрометированы ключи. Возможны и другие причины отзыва, например прекращение деятельности организации, которой выдан сертификат.
Для отзыва сертификатов удостоверяющий центр выпускает и распространяет по всем своим пользователям список отзыва сертификатов (certificate revocation list — CRL).
Процедура проверки корректности сертификата может включать или не включать проверку списка отзыва сертификатов. Как правило, решение об использовании списка отзыва сертификатов определяется регламентом удостоверяющего центра.
Библиотека OpenSSL предоставляет возможность проверки списка отзыва сертификатов, но по умолчанию такая проверка не проводится. Для того, чтобы такая проверка производилась, необходимо явным образом это указать.
Срок действия списка отзыва, как правило, заметно меньше, чем срок действия сертификата. Поэтому если списки отзыва используются, они должны регулярно обновляться.
Если в конфигурации указан устаревший список отзыва, то все сертификаты, выданные удостоверяющим центром, которому принадлежит данный список отзыва, будут считаться некорректными.
Онлайн-протокол проверки статуса сертификатов
Существует альтернативный способ проверки отзыва сертификатов — так называемый online-протокол проверки статуса сертификата (OCSP).
Для использования этого протокола необходимо наличие сервера, обычно принадлежащего удостоверяющему центру, который располагает актуальной информацией о статусе сертификатов, выпущенных этим удостоверяющим центром, и имеет специальный ключ, область применения которого — подпись OCSP-ответов.
В случае использования OCSP-сервера нет необходимости копировать списки отзыва на все машины, где может понадобиться проверка сертификатов. Статус сертификата запрашивается с сервера непосредственно в момент проверки.
Проверка принадлежности серверных сертификатов
Поскольку сертификаты серверов передаются открыто, то существует возможность, что злоумышленник, притворяющийся сервером, просто возьмет сертификат соответствующего сервера и отдаст его для аутентификации. Поэтому при аутентификации необходимо убедиться, что сертификат действительно принадлежит именно этому серверу.
Для этого следует убедиться, что у сервера есть не только сертификат, но и соответствующий ему закрытый ключ.
- Клиент высылает серверу некоторый набор данных, заранее неизвестный серверу.
- Сервер подписывает этот набор данных на своем закрытом ключе и пересылает результат обратно клиенту.
- Клиент, которому исходные данные известны, проверяет подпись под ними, пользуясь сертификатом сервера.
Таким образом, клиент убеждается, что сервер располагает не только данным сертификатом, но и соответствующим сертификату закрытым ключом.
Сертификат сервера и DNS
Любой сертификат на открытый ключ включает информацию о том, кто является его владельцем. В случае сертификатов серверов TLS это выполняется с помощью указания сетевого имени (DNS) сервера в поле CommonName.
Если сервер имеет несколько сетевых имен, то аутентификация считается успешной только в том случае, если предъявленный сервером сертификат соответствует именно тому сетевому имени, которое клиент использовал для установления соединения.
Необходимо иметь в виду, что если при аутентификации происходит ошибка (сетевое имя не совпадает с указанным в сертификате), большинство приложений дает возможность все-таки установить TLS-соединение. При этом выводится диалоговое окно, содержащее предупреждение следующего содержания:
Вы попытались установить соединение с [сетевое имя сервера]. Однако представленный сертификат безопасности принадлежит [сетевое имя, указанное в сертификате]. Имеется вероятность, хотя и небольшая, что кто-то может попытаться перехватить ваше соединение с этим вебсайтом.
Если вы подозреваете, что показанный сертификат не принадлежит [сетевое имя сервера], пожалуйста, откажитесь от соединения и уведомите администратора сайта.
- Просмотреть сертификат
- Ок (установить TLS-соединение)
- Отмена (отказаться от TLS-соединения)
- Помощь (справка)
В этом случае ответственность за безопасность устанавливаемого TLS-соединения полностью берет на себя пользователь.
Такая ситуация может возникнуть, например, если в сертификате указано сетевое имя вида http://www.name.com, а пользователь пытается установить соединение, используя сетевое имя вида http://name.com.
Следует также обратить внимание, что аутентификация сервера производится до того, как клиент передал какие-то данные прикладного протокола (например протокола http — скажем, на какую страницу он хочет попасть). Поэтому в момент аутентификации серверу ничего не известно о клиенте и о том, что клиент будет запрашивать у сервера. Известен только IP-адрес, на который пришел клиент (даже в том случае, если у сервера их несколько, к началу аутентификации уже известно, к какому IP-адресу обратился клиент).
либо эти сервера должны использовать сертификат, соответствующий всем этим именам сразу (т.е. в CommonName указать *.domain);
либо указать все сетевые имена этих серверов в поле сертификата SubjectAltName, которое позволяет указать несколько имен;
Типичные ошибки при работе с сертификатами
Самоподписанный сертификат сервера
Многие программы-сервера при установке предлагают установить самоподписанный сертификат сервера. Следует обязательно иметь в виду, что такой сертификат не предоставляет никакой гарантии безопасности соединения. При проверке отличить такой сертификат от любого другого сертификата с тем же доменным именем невозможно, поэтому его очень легко подменить. Самоподписанный сертификат сервера можно использовать только для проверки работоспособности установленного сервера.
Установка корневого сертификата удостоверяющего центра — отдельное, явное и контролируемое пользователем действие, которое предпринимается в начале работы с сервисом. Пользователь точно знает, что за сертификат он установил, выполняет проверку цифрового отпечатка (fingerprint), который также необходимо получить. После того, как корневой сертификат удостоверяющего центра установлен в системе и помещен в соответствующее хранилище доверенных сертификатов, пользователь получает возможность надежной аутентификации сервера по сертификату сервера, подписанному на корневом сертификате удостоверяющего центра.
В состав дистрибутивов операционных систем и криптографических программ включаются корневые сертификаты некоторых удостоверяющих центров. Это делается для того, чтобы криптографические программы с момента установки считали эти удостоверяющие центры доверенными и могли работать с сертификатами, выданными этими удостоверяющими центрами. Так, в состав ОС Windows входят корневые сертификаты известного удостоверяющего центра VeriSign. Среди таких предустановленных сертификатов в настоящее время нет ни одного сертификата с алгоритмами ГОСТ.
Пользователям обязательно следует учитывать, что данные корневые сертификаты часто являются доверенными исключительно с технической точки зрения (т.к. они установлены в соответствующем хранилище). На самом деле считать их доверенными нельзя, потому что пользователь при установке этих сертификатов не имел возможность проверить их корректность путем сверки цифрового отпечатка.
Способы хранения сертификатов удостоверяющих центров
Текстовый файл, в котором содержатся все необходимые сертификаты и списки отзывов в PEM-формате.
В утилите openssl такой файл указывается с помощью опции -CAfile.
Недостаток этого способа — содержимое файла полностью загружается в память. Поэтому при использовании большого количества УЦ или при использовании УЦ с объемными CRL лучше использовать второй способ.
Каталог, в котором содержатся сертификаты и CRL в виде отдельных файлов.
Для удобства и быстроты работы с сертификатами в этом каталоге следует использовать утилиту c_rehash, которая создает ссылки на файлы сертификатов, содержащихся в каталоге-хранилище, с именами в виде шестнадцатеричных тридцатидвухбитных хэш-сумм наименований удостоверяющих центров. Благодаря наличию таких хэшированных имен библиотека OpenSSL может мгновенно найти нужный сертификат или CRL.
В этом случае размеры и количество файлов неограничены, так как в процессе работы читается и загружается только нужная информация.
Поскольку утилита c_rehash работает только с файлами с расширением .pem, следует помещать файлы сертификатов и CRL в каталог-хранилище именно с таким расширением.
В принципе, библиотека OpenSSL позволяет реализовать любые другие способы хранения сертификатов, например в базе данных или LDAP-каталоге. Но с подобными реализациями должно работать непосредственно приложение (см. соответствующий раздел руководства программиста по libcrypto).
Хранение собственного сертификата сервера и его закрытого ключа
Как правило, собственный сертификат сервера и его закрытый ключ хранятся непосредственно на сервере либо в отдельных файлах, либо в одном текстовом файле в PEM-формате.
Защита собственного сертификата сертификата сервера и его закрытого ключа должна осуществляться с помощью прав доступа файловой системы.
Закрытый ключ также может быть дополнительно защищен паролем (пассфразой). Но в таком случае при каждой перезагрузке сервера кто-то должен вводить этот пароль, что не всегда возможно (в частности, если перезагрузка выполняется дистанционно).
Поэтому для серверных приложений обычно используют закрытые ключи, защищенные только правами доступа файловой системы. Для интерактивных приложений лучше использовать ключи, защищенные на пароле.
Некоторые приложения, например OpenVPN, позволяют хранить собственные сертификаты и ключ в формате PKCS#12.
Хранение сертификатов промежуточных удостоверяющих центров
Форматы кодирования криптографических документов DER и PEM
OpenSSL поддерживает два основных формата, определяющих кодирование криптографических документов: DER и PEM.
DER — бинарные файлы.
PEM — текстовые файлы.
Криптографический документ в формате PEM имеет вид
-----BEGIN ----- -----END -----
Т.е. содержание документа окружается заголовками специального вида, состоящими из пяти знаков «-», слов begin и end и указания типа документа (CERTIFICATE, CRL и т.д.)
Благодаря наличию таких заголовков в одном файле может содержаться несколько документов в формате PEM: например, цепочка сертификатов или сертификат и его закрытый ключ.
По умолчанию в OpenSSL используется именно формат PEM.
Форматы, определяющие структуру файлов, содержащих криптографическую информацию
Файлы, содержащие цепочки сертификатов, сертификаты и ассоциированные с ними ключи, могут представляться в нескольких форматах, определяющих состав и строение файлов, содержащих ключевую информацию; сама эта информация кодируется в вышеописанных форматах PEM и DER.
PKCS#7 — формат защищенных сообщений, который, кроме самого сообщения, может содержать необходимые для работы с ним сертификаты и CRL.
Многие удостоверяющие центры распространяют свои сертификаты и CRL в виде PKCS#7-документов, в которых нет сообщения, есть только служебная информация.
PKCS#7-документ может быть закодирован и формате DER, и в формате PEM.
Расширения файлов сертификатов могут быть .cer или .crt . Расширение служебных PKCS#7-сообщений обычно бывает .p7b или .p7f. Эти расширения никак не коррелируют с форматами DER и PEM, т.е. файл с любым из этих расширений может быть закодирован как в формате DER, так и в формате PEM.
PKCS#12 — формат для переноса сертификата и связанного с ним закрытого ключа с машины на машину или для резервного копирования. В этом формате могут также содержаться сертификаты удостоверяющего центра.
Файлы формата PKCS#12 всегда кодируются в формате DER. Эти файлы требуют особенно пристального внимания, поскольку содержат закрытый ключ; при неосторожном обращении с таким файлом закрытый ключ легко скомпрометировать. Как правило, эти файлы защищены на пароле.
Расширение файлов формата PKCS#12 либо .p12, либо .pfx .
OpenSSL предоставляет возможность преобразования файлов в формате DER в формат PEM. Для этого используются команды:
openssl x509 -in filename.der -inform der -out filename.pem
Для списков отзывов:
openssl crl -in filename.der -inform der -out filename.pem
openssl pkcs7 -in filename.der -inform der -out filename.pem
Для извлечения сертификатов из сообщений формата PKCS#7:
openssl pkcs7 -in filename.pem -print\_certs
Создание SSL-сертификата
Возникла у меня однажды необходимость установить SSL-сертификат на почтовый сервер с dovecot-ом. Так как сервер использовался весьма небольшим кругом лиц, то необходимости иметь настоящий сертификат, удостоверенным признанным центром сертификации, не было. Поэтому для экономии времени и денег было принято решение просто создать самоподписанный SSL-сертификат.
После непродолжительного курения man-ов родилось следующее решение:
openssl req -new -x509 -days 3650 -sha256 -newkey rsa:2048 \ -nodes -keyform PEM -keyout my.domain.key -outform PEM \ -out my.domain.crt -subj '/O=Some Org/CN=mail.my.domain'
O – название организации, CN – название сервера. Должно совпадать с именем хоста. Такой сертификат будет действителен 10 лет с момента создания (параметр -days). Файл my.domain.crt нужно положить в директорию /etc/pki/dovecot/certs, а файл my.domain.key – в директорию /etc/pki/dovecot/private, предварительно переименовав их в dovecot.pem или изменив параметры ssl_cert_file и ssl_key_file в конфигурационном файле , чтобы привести их в соответствие реальным именам файлов с ключём с сертификатом.
Для того, чтобы экспортировать данный сертификат в формат PKCS#12, который используется многими приложениями от Microsoft, используется следующая команда:
openssl pkcs12 -export -out dovecot.pfx -in dovecot.pem \ -name "mycert" -inkey ../private/dovecot.pem
В данном случае она запускалась из директории /etc/pki/dovecot/certs.
Затем полученный сертификат в файле dovecot.pfx можно импортировать в храниилище доверенных сертификатов того приложения, которое работает с нашим почтовым сервером. Например, в Outlook Express 6 это делается так:
меню «Сервис» → «Параметры. » → вкладка «Безопасность» → кнопка «Сертификаты. » → вкладка «Доверенные корневые центры сертификации» → кнопка «Импорт. «, выбрать найл dovecot.pfx, в окне запроса пароля поля оставить пустыми, далее везде согласиться со значениями по-умолчанию.
Данная процедура избавляет от появления предупреждающего сообщения с текстом «Используемый сервер имеет сертификат безопасности, который невозможно проверить» при каждом новом сеансе связи с почтовым сервером:
Обратная операция (преобразование pfx в pem):
openssl pkcs12 -in dovecot.pfx -out dovecot.pem -nodes
openssl pkcs12 -in dovecot.pfx -out dovecot.pem
Во втором случае случае будет запрошен пароль для приватного ключа.
Для проверки конфигурации можно заставить openssl выступить в роли почтового клиента следующим образом:
openssl s_client -connect mail.someorg.net:995
и потом использовать команды протокола POP3 для дальнейшего диалога с сервером.
Если надо получить настоящий сертификат от признанного центра сертификации (Certificate Authority или сокращённо CA), то запрос на подписание сертификата (CSR) создаётся так (нужно будет ввести в диалоговом режиме некоторую информацию об организации, инициирующей такой запрос):
openssl req -new -newkey rsa:2048 -sha256 -nodes -keyout my.domain.key -out my.domain.req Generating a 2048 bit RSA private key . +++ . +++ writing new private key to 'my.domain.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:b>UAb> State or Province Name (full name) []:b>Kyivska obl.b> Locality Name (eg, city) [Default City]:b>Irpinb> Organization Name (eg, company) [Default Company Ltd]:b>Roga and Kopitab> Organizational Unit Name (eg, section) []:b>It Dptb> Common Name (eg, your name or your server's hostname) []:my.domain Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Здесь введенные оператором данные выделены жирным (чтобы было понятнее).
Если хочется создать CSR без лишних вопросов (чтоб бывает нужно в различных скриптах), то это можно сделать вот так:
openssl req -new -newkey rsa:2048 -sha256 -nodes -keyout my.domain.key -out my.domain.req -subj '/C=US/ST=Florida/L=Miami/O=Cool IT Company/OU=Hosting Team/CN=my.domain/[email protected]/subjectAltName=DNS.1=www.my.domain,DNS.2=anothersubdom.my.domain'
Аббревиатуры означают следующее:
C – Country (страна)
ST – State (штат, кантон область страны и.т.п)
L – Locality (обычно город)
O – Organization (название компании)
OU – Organization Unit (отдел компании)
CN – Common Name (основной домен, который должен покрываться сертификатом)
emailAddress – адрес электронной почты
subjectAltName – альтернативные домены (обычно там сабдомен www, если выпускается multi-domain aka UC-сертификат, то доменов в атрибуте «subjectAltName» может быть больше одного).
В результате в файле my.domain.key появится приватный ключ, а в файле my.domain.req – собственно сам certificate signing request (CSR), который нужно потом будет отправить в CA.
А вот так можно проверить соответствие пары сертификат-ключ:
$ openssl x509 -noout -modulus -in my.domain.crt Modulus=AF89EDE626F8F022D1E9A8E8C1852AC0DCA471B430737358C31DA85BF5F56BBA0F2E42A77501636E8D508EA0832822DEEEB517121B4E188E60E0E46E36971534696CE75453A23361E8B3EFB2E9B8056E6F2043605B5698D6B4AE172BD48437456C3E076ADCF613D6BB83CA4755D6641C473FBBFD346552AD804436D25673DF7FEE4CF19ABC003A7799A4BAE428A11C4611A5018BBD708AC655D043C36BCEE62F0B1FCFD9A7C2D05A284DA1E9185D8D43641D5AEF855472085DDC30105CE829922E39E2327CE8BC0C216403753303EB7DE4DF97ED1B8BCA0B80FDCD597706299BD0B34E6CCB5C878EC4BB6484F1B4D0D6E16B9FFB6ED2C3327CF7DEE2AA1C5F1F $ openssl rsa -noout -modulus -in my.domain.key Modulus=AF89EDE626F8F022D1E9A8E8C1852AC0DCA471B430737358C31DA85BF5F56BBA0F2E42A77501636E8D508EA0832822DEEEB517121B4E188E60E0E46E36971534696CE75453A23361E8B3EFB2E9B8056E6F2043605B5698D6B4AE172BD48437456C3E076ADCF613D6BB83CA4755D6641C473FBBFD346552AD804436D25673DF7FEE4CF19ABC003A7799A4BAE428A11C4611A5018BBD708AC655D043C36BCEE62F0B1FCFD9A7C2D05A284DA1E9185D8D43641D5AEF855472085DDC30105CE829922E39E2327CE8BC0C216403753303EB7DE4DF97ED1B8BCA0B80FDCD597706299BD0B34E6CCB5C878EC4BB6484F1B4D0D6E16B9FFB6ED2C3327CF7DEE2AA1C5F1F
Если вывод обоих команд совпадает, то значит ключ соответствует сертификату (сертификат был сгенерирован на основе этого ключа, а не какого-то другого). Может пригодится, если какой-то нерадивый клиент сам покупал сертификат, а потом прислал черт знает что и сам запутался в этом.
UPDATE от 2014-06-26: По мотивам вышеизложенного и камментов ниже свяал себе такой скриптец, чтобы быстро смотреть инфу по сертификатам:
#!/bin/bash cert="$1" if [ -z "$cert" ]; then echo "Checking for validity intervals for certificates in current dir:" for c in *.crt ; do echo "File |$c|:" openssl x509 -text -noout -in $c | grep -A 1 -E "Alternative|Before|After" echo "=============================================================" done echo "Checking for mutual correspondence of keys and certificates in current dir (values whould match):" for c in `ls *.crt | grep -vE "intermediate|bundle"` ; do echo "File |$c|" openssl x509 -noout -modulus -in $c | openssl md5 done for k in *.key ; do echo "File |$k|" openssl rsa -noout -modulus -in $k | openssl md5 done else echo "File |$cert|:" openssl x509 -text -noout -in $cert | grep -A 1 -E "Alternative|Before|After" fi
Ну и напоследок плохая новость для тех, кто использовал алгоритм SHA-1 при генерации ключей. Он уже признан устаревшим, недостаточно безопасным и скоро сайты, использующие SHA-1-сертификаты, будут признаны ненадежными. Процесс утери доверия к SHA-1 сертификатам будет происходить через такие этапы:
- ноябрь 2014 – Google Chrome начинает показывать предупреждение для сайтов с SHA-1 SSL сертификатами, срок действия которых заканчивается в 2017 году;
- декабрь 2014 – Google Chrome начинает показывать предупреждение для сайтов с SHA-1 SSL сертификатами, срок действия которых заканчивается после 01.06.2016;
- январь 2015 – Google Chrome начинает показывать предупреждение для сайтов с SHA-1 SSL сертификатами, срок действия которых заканчивается в 2016-м году;
- 1-ое января 2016 – Microsoft прекращает доверять SHA-1 сертификатам для подписи кода (Code Signing), которые не имеют временных меток (timestamp);
- 1-ое января 2017 – Microsoft и Mozilla перестанут доверять любым SHA-1 SSL сертификатам.
Упомянутое предупреждение от Google Chrome версии 41.0.2272.89 по состоянию на 2015-03-16 выглядит так: «The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it.» и его можно увидеть если кликнуть по пиктограмме в строке адреса у левого её края.
Кстати, если кому нужен недорогой SSL-сертификат (всего за 14$/год), обращайтесь.
Больше информации о практическом использовании OpenSSL можно найти тут: xgu.ru
Отличный сервис для анализа конфигурации TLS, поиска и устранения проблем: https://www.ssllabs.com/ssltest/analyze.html.
- yum: лечим [Errno 14] problem making ssl connection
- Печать из windows на cups-принтер
- Настройка печати через RDP с WIN-сервера на Linux-клиент
- Конфиг haproxy для оценки A от SSLLabs.com