Моя компания предоставила клиенту приложение на основе Tomcat / MySQL, которое по умолчанию использует http. По просьбе клиента я включил использование https, создав самозаверяющий сертификат. Это сработало с учетом ожидаемой ошибки браузера при использовании самозаверяющего сертификата.
После проверки на проникновение они решили, что нам нужно отключить некоторые устаревшие протоколы ssl и шифры, поэтому я изменил коннектор ssl в моем файле tomcat server.xml, чтобы он выглядел так:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_WITH_AES_128_GCM_SHA256"
keystoreFile="/path/to/keystore/file"
keystorePass="password" />
Это удовлетворило тест на проникновение, и приложение продолжало работать во всех трех основных браузерах (Chrome, Firefox и IE). Тем не менее, тест на проникновение также показал, что в идеале мы не должны использовать самозаверяющий сертификат, поэтому, следуя эти гиды, Я создал CSR и попросил клиента создать сертификат, подписанный для его внутреннего домена (к серверу можно было получить доступ по нескольким различным URL-адресам, следовательно, необходимо создать CSR с SAN).
Я добавил сертификат в новое хранилище ключей и соответствующим образом изменил путь в файле server.xml. Теперь, когда я пытаюсь подключиться, я получаю следующую ошибку (это от Firefox, но все браузеры выдают аналогичную ошибку):
Безопасное соединение не удалось
Ошибка при подключении к 172.31.1.36:8443. Невозможно безопасно обмениваться данными с одноранговым узлом: нет общих алгоритмов шифрования. Код ошибки: SSL_ERROR_NO_CYPHER_OVERLAP
Страница, которую вы пытаетесь просмотреть, не может быть отображена, потому что не удалось проверить подлинность полученных данных. Пожалуйста, свяжитесь с владельцами веб-сайтов, чтобы сообщить им об этой проблеме.
Насколько я понимаю, сертификат не контролирует, какие шифры или протоколы следует использовать, поэтому я не понимаю, почему это произошло. Это ошибка, которую я сделал при создании CSR, или это может быть ошибка, которую сделал клиент при создании сертификата?
-РЕДАКТИРОВАТЬ-
Кажется, я везде получаю ошибки. Если я попытаюсь импортировать ключ в хранилище ключей, я получу следующее:
cat <keyfile> | openssl pkcs12 -export -out <keystore>.p12
Enter pass phrase:
unable to load certificates
Или это:
keytool -importkeystore -srckeystore <keyfile> -srcstoretype pkcs12 -destkeystore <keystore>.jks
Enter destination keystore password:
Re-enter new password:
Enter source keystore password:
keytool error: java.io.IOException: toDerInputStream rejects tag type 45
У меня есть заказчик, чтобы отправить мне цепочку сертификатов, и когда я пытаюсь импортировать ее, я получаю эту ошибку:
keytool -import -trustcacerts -alias tomcat -file <certchain>.p7b -keystore <keystorefile>.jks
Enter keystore password:
keytool error: java.lang.Exception: Input not an X.509 certificate
Я нашел несколько решений о том, как преобразовать файл pkcs в x.509, но затем у меня появились другие ошибки, поэтому я полностью застрял.
Основная причина всех проблем заключалась в том, что сертификат был в неправильном формате.
Следуя информации Вот Я обнаружил, что сертификат действительно был в формате DER. Я преобразовал его следующим образом:
openssl x509 -inform der -in certfile.cer -out new_certfile.pem
Сообщение об ошибке - отвлекающий маневр.
При настройке MikroTik для Webfig https access, вы получите эту ошибку, если просто создадите и используете сертификат, не подписанный центром сертификации. Когда браузер видит неподписанный сертификат, он выдает ошибку:
"Код ошибки: SSL_ERROR_NO_CYPHER_OVERLAP"
Не спускайтесь в кроличью нору, исследуя несовместимые шифры и тому подобное: вам просто нужно подписать свой сертификат в ЦС, и все будет работать, как ожидалось.
Ниже приводится MikroTik-специфическая процедура для устранения ошибки.
Не просто вырезать и вставить: Пожалуйста, замените мои заполнители разумными значениями ;-)
/certificate add name=CAyourDomain-template common-name=CAyourDomain country=GB days-valid=3650 key-size=4096 locality="Your City" organization="Your Organization" state=Hertfordshire trusted=yes unit="Technical Services" subject-alt-name="IP:XXX.XXX.XXX.XXX" key-usage=digital-signature,key-cert-sign,crl-sign;
/certificate sign CAyourDomain-template ca-crl-host="XXX.XXX.XXX.XXX" name=CAyourDomain
/certificate add name=webfig-template common-name="webfig" country=GB days-valid=3650 key-size=4096 locality="Your City" organization="Your Organization" state=Hertfordshire trusted=yes unit="Technical Services" subject-alt-name="IP:XXX.XXX.XXX.XXX" key-usage=digital-signature,key-encipherment,data-encipherment,tls-server,tls-client;
/certificate sign webfig-template ca=CAyourDomain name=webfig
/certificate set webfig trusted=yes
Теперь это "webfig"сертификат был подписан центром сертификации, вам, наконец, нужно указать его здесь, чтобы использовать его:
"IP">"Сервисы"и включить"www-ssl"и укажите"webfig"сертификат создан, и доступ к подсети HTTPS должен быть разрешен с