Разница между двухсторонним SSL и единой аутентификацией в Artemis - PullRequest
Новая
       3

Разница между двухсторонним SSL и единой аутентификацией в Artemis

0 голосов
/ 03 февраля 2020

У меня есть Artemis с 3-мя брокерами (1-master и 2-slave), и я хотел бы использовать SSL между ними и клиентом. Теперь я использую самоподписанные сертификаты, которые были сгенерированы следующим образом: 

# Create a broker key and cert - import the keypair and cert into the broker keystore
openssl req -newkey rsa:2048 -nodes -keyout broker_keypair.pem -x509 -days 65000 -out broker_cert.pem
openssl pkcs12 -inkey broker_keypair.pem -in broker_cert.pem -export -out broker_ks.p12

# Create a client key and cert - import the keypair and cert into the client keystore
openssl req -newkey rsa:2048 -nodes -keyout client_keypair.pem -x509 -days 65000 -out client_cert.pem
openssl pkcs12 -inkey client_keypair.pem -in client_cert.pem -export -out client_ks.p12

# Create a truststore for the broker, and import the client's certificate. This establishes that the broker "trusts" the client:
keytool -import -alias client -keystore broker_ts.p12 -file client_cert.pem -deststoretype pkcs12

# Create a truststore for the client, and import the broker's certificate. This establishes that the client "trusts" the broker:
keytool -import -alias broker -keystore client_ts.p12 -file broker_cert.pem -deststoretype pkcs12

мой брокер. xml для мастера: 

<?xml version='1.0'?>

<configuration xmlns="urn:activemq"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xi="http://www.w3.org/2001/XInclude"
               xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">

   <core xmlns="urn:activemq:core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:activemq:core ">

      <name>0.0.0.0</name>

      <persistence-enabled>true</persistence-enabled>

      <journal-type>ASYNCIO</journal-type>

      <paging-directory>data/paging</paging-directory>

      <bindings-directory>data/bindings</bindings-directory>

      <journal-directory>data/journal</journal-directory>

      <large-messages-directory>data/large-messages</large-messages-directory>

      <journal-datasync>true</journal-datasync>

      <journal-min-files>2</journal-min-files>

      <journal-pool-files>10</journal-pool-files>

      <journal-device-block-size>4096</journal-device-block-size>

      <journal-file-size>10M</journal-file-size>

      <journal-buffer-timeout>28000</journal-buffer-timeout>

      <journal-max-io>4096</journal-max-io>

      <disk-scan-period>5000</disk-scan-period>

      <max-disk-usage>100</max-disk-usage>

      <critical-analyzer>true</critical-analyzer>

      <critical-analyzer-timeout>120000</critical-analyzer-timeout>

      <critical-analyzer-check-period>60000</critical-analyzer-check-period>

      <critical-analyzer-policy>HALT</critical-analyzer-policy>

      <page-sync-timeout>1628000</page-sync-timeout>

      <global-max-size>204Mb</global-max-size>

      <connectors>
         <connector name="netty-connector">tcp://amq1:61616?sslEnabled=true;keyStorePath=client_ks.p12;keyStorePassword=artemis;trustStorePath=client_ts.p12;trustStorePassword=artemis</connector>
      </connectors>
      <acceptors>
         <acceptor name="netty-acceptor">tcp://amq1:61616?sslEnabled=true;keyStorePath=broker_ks.p12;keyStorePassword=artemis;trustStorePath=broker_ts.p12;trustStorePassword=artemis;needClientAuth=true</acceptor>
      </acceptors>

      <cluster-connections>
         <cluster-connection name="my-cluster">
            <address>amq</address>
            <connector-ref>netty-connector</connector-ref>
            <retry-interval>1000</retry-interval>
            <retry-interval-multiplier>3</retry-interval-multiplier>
            <use-duplicate-detection>true</use-duplicate-detection>
            <message-load-balancing>STRICT</message-load-balancing>
            <discovery-group-ref discovery-group-name="my-discovery-group"/>
         </cluster-connection>
      </cluster-connections>

      <broadcast-groups>
         <broadcast-group name="my-broadcast-group">
            <local-bind-address>amq1</local-bind-address>
            <local-bind-port>9876</local-bind-port>
            <group-address>231.7.7.7</group-address>
            <group-port>9876</group-port>
            <broadcast-period>2000</broadcast-period>
            <connector-ref>netty-connector</connector-ref>
         </broadcast-group>
      </broadcast-groups>   

      <discovery-groups>
         <discovery-group name="my-discovery-group">
            <local-bind-address>amq1</local-bind-address>
            <local-bind-port>9876</local-bind-port>
             <group-address>231.7.7.7</group-address>
             <group-port>9876</group-port>
             <refresh-timeout>10000</refresh-timeout>
         </discovery-group>
      </discovery-groups>

      <network-check-list>amq1,amq2,amq3</network-check-list>   
      <network-check-period>5000</network-check-period>
      <network-check-timeout>1000</network-check-timeout>
      <network-check-ping-command>ping -c 1 -t %d %s</network-check-ping-command>
      <network-check-ping6-command>ping6 -c 1 %2$s</network-check-ping6-command>

      <!-- Other config -->
      <ha-policy>
        <replication>
          <master>
            <check-for-live-server>true</check-for-live-server>
          </master>
        </replication>
      </ha-policy>

      <security-settings>
         <security-setting match="#">
            <permission type="createNonDurableQueue" roles="amq"/>
            <permission type="deleteNonDurableQueue" roles="amq"/>
            <permission type="createDurableQueue" roles="amq"/>
            <permission type="deleteDurableQueue" roles="amq"/>
            <permission type="createAddress" roles="amq"/>
            <permission type="deleteAddress" roles="amq"/>
            <permission type="consume" roles="amq"/>
            <permission type="browse" roles="amq"/>
            <permission type="send" roles="amq"/>
            <!-- we need this otherwise ./artemis data imp wouldn't work -->
            <permission type="manage" roles="amq"/>
         </security-setting>
      </security-settings>

      <addresses>
         <address name="exampleQueue">
            <anycast>
               <queue name="exampleQueue"/>
            </anycast>
         </address>
         <address name="DLQ">
            <anycast>
               <queue name="DLQ" />
            </anycast>
         </address>
         <address name="ExpiryQueue">
            <anycast>
               <queue name="ExpiryQueue" />
            </anycast>
         </address>
      </addresses>

      <address-settings>
         <!-- if you define auto-create on certain queues, management has to be auto-create -->
         <address-setting match="activemq.management#">
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>
            <!-- with -1 only the global-max-size is in use for limiting -->
            <max-size-bytes>-1</max-size-bytes>
            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>PAGE</address-full-policy>
            <auto-create-queues>true</auto-create-queues>
            <auto-create-addresses>true</auto-create-addresses>
            <auto-create-jms-queues>true</auto-create-jms-queues>
            <auto-create-jms-topics>true</auto-create-jms-topics>
         </address-setting>
         <!--default for catch all-->
         <address-setting match="#">
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>
            <!-- with -1 only the global-max-size is in use for limiting -->
            <max-size-bytes>-1</max-size-bytes>
            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>PAGE</address-full-policy>
            <auto-create-queues>true</auto-create-queues>
            <auto-create-addresses>true</auto-create-addresses>
            <auto-create-jms-queues>true</auto-create-jms-queues>
            <auto-create-jms-topics>true</auto-create-jms-topics>
         </address-setting>
         <address-setting match="exampleQueue">            
            <dead-letter-address>DLQ</dead-letter-address>                      
            <redelivery-delay>1000</redelivery-delay>    
            <max-delivery-attempts>3</max-delivery-attempts>
            <max-size-bytes>-1</max-size-bytes>
            <page-size-bytes>1048576</page-size-bytes>
            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>PAGE</address-full-policy>
        </address-setting>
      </address-settings>
   </core>
</configuration>

для подчиненного устройства - это почти та же структура. Я не буду публиковать его.

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

Спасибо

1 Ответ

1 голос
/ 04 февраля 2020

В большинстве случаев использования SSL используется односторонний SSL. В этих случаях сервер (будь то веб-сервер, файловый сервер, брокер сообщений и т. Д. c.) Размещает сертификат SSL, и клиент должен «доверять» этому сертификату для успешного завершения рукопожатия SSL. Обычно SSL-сертификат сервера подписывается доверенным органом (например, VeriSign , Digicert , Thawte , et c.), И клиенты неявно доверяют им. Вот как подавляющее большинство SSL делается в сети.

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

С 2-сторонним (или «взаимным») SSL и сервером и клиент имеет сертификаты SSL, и сервер и клиент должны доверять сертификату другого, чтобы успешно завершить рукопожатие SSL. Этот тип конфигурации является относительно редким и обычно требуется только в средах с высокой степенью защиты, где все стороны должны установить явное доверие. Это также может быть полезно для клиентов ActiveMQ Artemis, поскольку для аутентификации могут использоваться данные сертификата вместо имени пользователя и пароля. Детали конфигурации для этого обсуждаются в документации по безопасности ActiveMQ Artemis .

Поскольку вы указали needClientAuth=true на acceptor в broker.xml, вам требуется двусторонний SSL , Транспортная документация ActiveMQ Artemis гласит:

needClientAuth

Это свойство только для acceptor. Он сообщает клиенту, подключающемуся к этому акцептору, что требуется двухсторонний SSL. Допустимые значения: true или false. Значение по умолчанию: false.

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

Конфигурация одностороннего SSL намного проще. Например, вам нужно будет только выполнить эти команды: 

# Create a broker key and cert - import the keypair and cert into the broker keystore
openssl req -newkey rsa:2048 -nodes -keyout broker_keypair.pem -x509 -days 65000 -out broker_cert.pem
openssl pkcs12 -inkey broker_keypair.pem -in broker_cert.pem -export -out broker_ks.p12

# Create a truststore for the client, and import the broker's certificate. This establishes that the client "trusts" the broker:
keytool -import -alias broker -keystore client_ts.p12 -file broker_cert.pem -deststoretype pkcs12

И ваши connectors и acceptors будут настроены так: 

<connectors>
   <connector name="netty-connector">tcp://amq1:61616?sslEnabled=true;trustStorePath=client_ts.p12;trustStorePassword=artemis</connector>
</connectors>
<acceptors>
   <acceptor name="netty-acceptor">tcp://amq1:61616?sslEnabled=true;keyStorePath=broker_ks.p12;keyStorePassword=artemis</acceptor>
</acceptors>
...