Фактически у нас есть два кластера, каждый с двумя серверами CentOS 7.5. Система 1 является кластером разработки с подстановочным сертификатом; Система 2 - это производственный кластер с не подстановочным сертификатом на внешнем сервере, но с подстановочным сертификатом на внутреннем сервере.
Мы запускаем Ruby на Rails на Apache с Passenger и внедряем с Capistrano. Мы пытаемся развернуть камень симметричного c -шифрования с помощью AWS Служба управления ключами (KMS) для хранения мастер-ключа клиента (https://rocketjob.github.io/symmetric-encryption/configuration.html).
Через некоторое время работы, оба сервера в Системе 1 (разработка) развернуты и работают успешно. Мы смогли успешно выполнить развертывание на внутреннем сервере системы 2 (производственной), но на этапе deploy:assets:precompile развертывания Capistrano внешний интерфейс - сервер с сертификатом без подстановочных знаков - не удался:
01 Seahorse::Client::NetworkingError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate)
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/aws-sdk-core-3.89.1/lib/seahorse/client/net_http/connection_pool.rb:299:in `start_session'
...
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/aws-sdk-kms-1.28.0/lib/aws-sdk-kms/client.rb:1375:in `decrypt'
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/symmetric-encryption-4.3.1/lib/symmetric_encryption/utils/aws.rb:56:in `block in decrypt'
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/symmetric-encryption-4.3.1/lib/symmetric_encryption/utils/aws.rb:129:in `auto_create_master_key'
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/symmetric-encryption-4.3.1/lib/symmetric_encryption/utils/aws.rb:55:in `decrypt'
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/symmetric-encryption-4.3.1/lib/symmetric_encryption/keystore/aws.rb:137:in `read'
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/symmetric-encryption-4.3.1/lib/symmetric_encryption/keystore.rb:168:in `read_key'
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/symmetric-encryption-4.3.1/lib/symmetric_encryption/cipher.rb:22:in `from_config'
01 /var/www/web-2/html/shared/bundle/ruby/2.6.0/gems/symmetric-encryption-4.3.1/lib/symmetric_encryption/config.rb:87:in `block in ciphers'
FYI, выполнение openssl s_client -connect s3-us-west-2.amazonaws.com:443 на каждом производственном сервере приводит к разным результатам, а внешний сервер выдает ошибку.
Вот внутренний сервер с подстановочным знаком:
-bash-4.2$ openssl s_client -connect s3-us-west-2.amazonaws.com:443
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Baltimore CA-2 G2
verify return:1
depth=0 C = US, ST = Washington, L = Seattle, O = "Amazon.com, Inc.", CN = *.s3-us-west-2.amazonaws.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=*.s3-us-west-2.amazonaws.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
---
Server certificate
-----BEGIN CERTIFICATE-----
--%<--snip-->%--
-----END CERTIFICATE-----
subject=/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=*.s3-us-west-2.amazonaws.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3727 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: B001EA6EC9FC5049EEE85A13DA0373634992E8AB907E4558BE64F5A26055223D
Session-ID-ctx:
Master-Key: DE8B5EBE0645974504E83FB6AE73CB54042EDA6B13FCC32A0B6C601EC2231E3627FE721ECE1F07CA48915D2A69195C67
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581341714
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
closed
И Вот внутренний сервер с сертификатом без подстановочных знаков:
-bash-4.2$ openssl s_client -connect s3-us-west-2.amazonaws.com:443
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Baltimore CA-2 G2
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=*.s3-us-west-2.amazonaws.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
---
Server certificate
-----BEGIN CERTIFICATE-----
--%<--snip-->%--
-----END CERTIFICATE-----
subject=/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=*.s3-us-west-2.amazonaws.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3727 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 002173BC9539FF9A0CAEAF4EE3699102D638784A30F505AAE679F26E0DA22EA0
Session-ID-ctx:
Master-Key: 252EF43EC4EB107FA27702CA5EDBEE894F8BAB9FD7B326EB581F49A666F21988543B7F0EF185F2E7D4D13E7E052A8B98
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581341716
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
closed
Мы думали, что, возможно, была проблема с нашей цепочкой сертификатов, но после прочтения и следования инструкциям в https://medium.com/@superseb / get- your-certificate-chain-right-4b117a9c0fce , мы подтвердили, что наш сертификат и цепочка сертификатов в порядке:
-bash-4.2$ openssl verify company.net.crt
company.net.crt: OK
-bash-4.2$ openssl x509 -in company.net.crt -noout -issuer
issuer= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-bash-4.2$ openssl x509 -noout -subject -in ca-bundle.crt
subject= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-bash-4.2$ openssl verify -CAfile ca-bundle.crt company.net.crt
company.net.crt: OK
Итак, каким-то образом мы можем получить два разных результата от openssl, в зависимости от контекста.
Мы также попытались инициализировать AWS с Aws.use_bundled_cert! согласно https://github.com/rubygems/rubygems/issues/2415#issuecomment -460998632 , но это не помогло. Я видел ссылки на выполнение следующей команды, но мы еще не пробовали этого, так как мы хотим исследовать это немного подробнее (и посмотрим, так ли это консенсус людей на этом сайте):
curl -fsSL curl.haxx.se/ca/cacert.pem -o "$(ruby -ropenssl -e 'puts OpenSSL::X509::DEFAULT_CERT_FILE')"
Таким образом, учитывая, что у нас проблема только с одной системой, которая не использует подстановочный сертификат, кажется, что у нас что-то неправильно сконфигурировано где-то между нашим сервером, симметричным c -шифрованным гемом или AWS (либо KMS, либо CMS ).
Очевидно, мы бы хотели решить нашу проблему, но даже предложения о том, как ее диагностировать, были бы очень благодарны. Обратите внимание, что мы впервые используем AWS KMS (в дополнение к симметрии c -шифрования).