<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Cisco SMA и сертификаты]]></title><description><![CDATA[<p dir="auto">Мы используем SMA для почтовой ретрансляционной среды у клиента. Конечные пользователи получают доступ к производственному интерфейсу HTTPS для карантина SPAM. Наша операционная команда использует интерфейс управления HTTPS для повседневной работы. Они используют старый веб-интерфейс и IP-адрес интерфейса управления, например<br />
<a href="https://10.a.b.c/" rel="nofollow ugc">https://10.a.b.c/</a><br />
. Мы установили один сертификат на устройстве. CN в этом сертификате совпадает с именем хоста, используемым конечными пользователями, и они видят действительный сертификат при доступе к карантину спама. Наша операционная команда видит тот же сертификат при доступе к устройству, и этот сертификат выглядит недействительным, потому что они используют IP-адрес. Кроме того, имя хоста, связанное с этим интерфейсом, не совпадает с CN сертификата, поэтому переход на использование имени хоста не устраняет это предупреждение. Мы думаем о переходе на новый веб-интерфейс. Для этого мы должны начать использовать имена хостов в интерфейсе управления и использовать действительный сертификат. Однако я не понимаю, как использовать разные сертификаты для производственного интерфейса и другого для интерфейса управления. Вопросы: Можно ли использовать разные сертификаты для разных интерфейсов/портов?<br />
Как это настроить? Единственное, что приходит мне в голову, — это указать все возможные имена хостов в поле SAN сертификата, но это раскрывает информацию о нашей среде (хотя и в небольшом объеме) конечным пользователям нашего клиента. Хенк</p>
]]></description><link>https://sla247.ru/forum/topic/2474/cisco-sma-и-сертификаты</link><generator>RSS for Node</generator><lastBuildDate>Fri, 15 May 2026 16:05:25 GMT</lastBuildDate><atom:link href="https://sla247.ru/forum/topic/2474.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 02 Mar 2026 21:16:36 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Cisco SMA и сертификаты on Mon, 02 Mar 2026 21:16:38 GMT]]></title><description><![CDATA[<p dir="auto">Интересно, почему так происходит, ведь на ESA это возможно. Мы также обычно подключаемся по IP-адресу mgmt, поэтому наши внутренние сертификаты поддерживают их. Но для доступа клиентов публичные сертификаты не допускают IP-адреса в полях SAN... Поэтому очень полезно иметь отдельные сертификаты для каждого интерфейса...</p>
]]></description><link>https://sla247.ru/forum/post/17293</link><guid isPermaLink="true">https://sla247.ru/forum/post/17293</guid><dc:creator><![CDATA[chrishklomp]]></dc:creator><pubDate>Mon, 02 Mar 2026 21:16:38 GMT</pubDate></item><item><title><![CDATA[Reply to Cisco SMA и сертификаты on Mon, 02 Mar 2026 21:16:37 GMT]]></title><description><![CDATA[<p dir="auto">На SMA невозможно назначить разные сертификаты разным интерфейсам. Вы правильно подошли к решению, сертификат SAN — лучший вариант в данном случае. SMA позволяет использовать разные сертификаты для разных функций, но не для интерфейсов.</p>
]]></description><link>https://sla247.ru/forum/post/17292</link><guid isPermaLink="true">https://sla247.ru/forum/post/17292</guid><dc:creator><![CDATA[Udupi Krishna.]]></dc:creator><pubDate>Mon, 02 Mar 2026 21:16:37 GMT</pubDate></item></channel></rss>