надеюсь, ты сможешь мне помочь. У меня есть приложение java, использующее mongodb 2.6.7. Теперь мне нужно перейти на версию 4.4.0. В процессе я решил реализовать TLS-соединение, и тут у меня начались проблемы. Время ожидания подключения истекло.
Чтобы упростить работу, я решил подключиться напрямую, используя оболочку mon go. Вот такая ситуация:
у меня активен сервер mongod на linux p c (ubuntu 20.04 - ip: 192.168.1.191, mongodb установлен 4.4.0, OpenSSL установлен 1.1.1f) , и я пытаюсь подключиться к windows 10 p c (версия 2004 года - ip: 192.168.1.193, mongodb установлен 4.4.0, OpenSSL установлен 1.1.1g). Я создал самоподписанный сертификат с помощью следующих команд:
openssl genrsa -des3 -passout pass:qwer -out ./demoCA/private/cakey.pem 4096
openssl req -new -x509 -days 730 -key ./demoCA/private/cakey.pem -passin pass:qwer -out ./demoCA/cacert.pem -subj '/C=LL/ST=lin/L=lin/O=lin/OU=lin/CN=lin' -outform PEM
cp ./demoCA/cacert.pem ./demoCA/certs/00.pem
cd ./demoCA/certs
ln -s 00.pem `openssl x509 -hash -noout -in 00.pem`.0
cd ..
cd ..
openssl genrsa -out ./private_key.pem 4096
openssl req -new -key ./private_key.pem -out ./request.pem -subj '/C=LL/ST=lin/L=lin/O=lin/OU=lin/CN=192.168.1.191' -outform PEM
openssl ca -in ./request.pem -passin pass:qwer
cp ./demoCA/newcerts/01.pem ./demoCA/certs/01.pem
cd ./demoCA/certs
ln -s 01.pem `openssl x509 -hash -noout -in 01.pem`.0
cd ..
cd ..
cat ./private_key.pem ./demoCA/certs/01.pem > ./certificate.pem
, затем я запустил mongod с помощью этой команды:
mongod --config /etc/mongod.conf
здесь mongod.conf:
# Where and how to store data.
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
# engine:
# mmapv1:
# wiredTiger:
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# network interfaces
net:
port: 27017
bindIp: 192.168.1.191
tls:
mode: requireTLS
certificateKeyFile: [ABSOLUTE_PATH]/certificate.pem
CAFile: [ABSOLUTE_PATH]/demoCA/cacert.pem
# how the process runs
processManagement:
timeZoneInfo: /usr/share/zoneinfo
#security:
security:
authorization: "enabled"
Я загрузил на свой Win p c certificate.pem и cacert.pem и попытался подключиться к:
mongo --tls --tlsCertificateKeyFile c:\ssl-cert-lin\certificate.pem --tlsCAFile c:\ssl-cert-lin\cacert.pem -u root -p test --authenticationDatabase mydb --host 192.168.1.191 --port 27017
результат:
Error: couldn't connect to server 192.168.1.191:27017, connection attempt failed: SocketException: The client and server cannot communicate, because they do not possess a common algorithm.
После тысячи попыток я попытался сделать наоборот, установив сервер mongodb на windows и подключившись из linux к окну. Я выполнил ту же процедуру создания сертификата, ту же конфигурацию mongod, те же параметры подключения с командой mon go (после загрузки сертификата win на linux). Команда Linux mon go правильно подключилась к серверу mongod windows.
Итак, я попытался проверить соединение напрямую с помощью OpenSSL, сохранив как сервер mon go (на linux, так и на windows ) живой. Из linux (ip: 192.168.1.191) я запустил команду:
root@btksrv:~# openssl s_client -connect 192.168.1.193:27017 -CAfile ./ssl-cert-win/cacert.pem
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 C = WW, ST = win, L = win, O = win, OU = win, CN = win
verify return:1
depth=0 C = WW, ST = win, O = win, OU = win, CN = 192.168.1.193
verify return:1
---
Certificate chain
0 s:C = WW, ST = win, O = win, OU = win, CN = 192.168.1.193
i:C = WW, ST = win, L = win, O = win, OU = win, CN = win
---
Server certificate
-----BEGIN CERTIFICATE-----
[lines removed...]
-----END CERTIFICATE-----
subject=C = WW, ST = win, O = win, OU = win, CN = 192.168.1.193
issuer=C = WW, ST = win, L = win, O = win, OU = win, CN = win
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 2248 bytes and written 453 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: B84B0000D21B35AF457FBA576C3C1A4BD42DEC5B1DAC2FA33203DEA6E88DE4E7
Session-ID-ctx:
Master-Key: CA4CEC4DE4AA5B67BC577CCA3DF7D5E5DF5ECEC9438592AAC9D7DDDB105E31FB8CB78DBBE962C0A90D99195ECD86FCBB
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1596710695
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
read:errno=0
Из windows (ip: 192.168.1.193) я запустил команду:
c:\>openssl s_client -connect 192.168.1.191:27017 -CAfile c:\ssl-cert-lin\cacert.pem
CONNECTED(00000120)
Can't use SSL_get_servername
depth=1 C = LL, ST = lin, L = lin, O = lin, OU = lin, CN = lin
verify return:1
depth=0 C = LL, ST = lin, O = lin, OU = lin, CN = 192.168.1.191
verify return:1
---
Certificate chain
0 s:C = LL, ST = lin, O = lin, OU = lin, CN = 192.168.1.191
i:C = LL, ST = lin, L = lin, O = lin, OU = lin, CN = lin
1 s:C = LL, ST = lin, L = lin, O = lin, OU = lin, CN = lin
i:C = LL, ST = lin, L = lin, O = lin, OU = lin, CN = lin
---
Server certificate
-----BEGIN CERTIFICATE-----
[lines removed...]
-----END CERTIFICATE-----
subject=C = LL, ST = lin, O = lin, OU = lin, CN = 192.168.1.191
issuer=C = LL, ST = lin, L = lin, O = lin, OU = lin, CN = lin
---
Acceptable client certificate CA names
C = LL, ST = lin, L = lin, O = lin, OU = lin, CN = lin
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3832 bytes and written 403 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 0D60B8F6140E7483DDE2D4D3B405E2C81FCC6C18C32B03DA811395A0ED9189A0
Session-ID-ctx:
Resumption PSK: 10782266BDE34F8820365AD13FCB606128B410B6D9DBC31D382542E17058975030B4B472A907730AB63573FBD7E900B3
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
[lines removed...]
Start Time: 1596711179
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: E3A023177260EC48FEF860C30FBF32986E6AA83EA897D5D4E68DD1418329B6C4
Session-ID-ctx:
Resumption PSK: BE969CD81BB54EFF67C1F877A29A15C40839767A145252BDD16BDC2E91242E069C8E04D4A3E3DA7D099120D78749EA12
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
[lines removed...]
Start Time: 1596711179
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
read:errno=0
Глядя на последние 2 блока кода, я думаю, есть протокол несоответствия ... Linux использовать TLS 1.3 и windows использовать протокол 1.2. Может в этом проблема? в этом случае как я могу решить? Иначе в чем может быть проблема? (и решение)
Заранее благодарим за помощь
Ps перед использованием mon go v4.4 Я пробовал v4.2 ... то же самое