Миграция Tomcat с 8.0 до 8.5, проверка подлинности сертификата клиента не работает - PullRequest
0 голосов
/ 22 января 2020

Мы обновляем наш сервер Tomcat с 8.0 до 8.5. Наш сервер должен поддерживать https, включая взаимную аутентификацию, certificateVerification, используя значения по умолчанию для параметров JSSE tomcat. в настоящее время кажется, что взаимная аутентификация не работает, потому что сервер не может проверить сертификат клиента.

Конфигурация коннектора в tomcat выглядит следующим образом:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true" >
         <SSLHostConfig truststoreFile="/opt/allot/conf/infra.truststore" truststoreType="JKS" truststorePassword="****"
                         certificateVerification="required" sslProtocol="TLS" protocols="TLSv1.2,+TLSv1.1,+TLSv1.0">
            <Certificate certificateKeystoreFile="/opt/allot/conf/infra.keystore"
                         certificateKeystoreType="JKS"
                         certificateKeystorePassword="****"
                         certificateKeyAlias="****" />
        </SSLHostConfig>
</Connector>

Я использовал анализатор WireShark для и вывод это:

No. Time    Source  Destination Protocol    Length  Info
260 5.228627    172.19.2.30 10.110.108.74   TCP 66  55710 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
261 5.230733    10.110.108.74   172.19.2.30 TCP 66  443 → 55710 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1387 SACK_PERM=1 WS=128
262 5.230831    172.19.2.30 10.110.108.74   TCP 54  55710 → 443 [ACK] Seq=1 Ack=1 Win=131584 Len=0
263 5.252688    172.19.2.30 10.110.108.74   TLSv1.2 238 Client Hello
264 5.254772    10.110.108.74   172.19.2.30 TCP 56  443 → 55710 [ACK] Seq=1 Ack=185 Win=30336 Len=0
265 5.268445    10.110.108.74   172.19.2.30 TCP 1441    443 → 55710 [ACK] Seq=1 Ack=185 Win=30336 Len=1387 [TCP segment of a reassembled PDU]
266 5.268564    10.110.108.74   172.19.2.30 TLSv1.2 887 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
267 5.268607    172.19.2.30 10.110.108.74   TCP 54  55710 → 443 [ACK] Seq=185 Ack=2221 Win=131584 Len=0
268 5.329682    172.19.2.30 10.110.108.74   TLSv1.2 136 Certificate, Client Key Exchange
269 5.333364    10.110.108.74   172.19.2.30 TLSv1.2 61  Alert (Level: Fatal, Description: Bad Certificate)
270 5.333365    10.110.108.74   172.19.2.30 TCP 56  443 → 55710 [FIN, ACK] Seq=2228 Ack=267 Win=30336 Len=0
271 5.333456    172.19.2.30 10.110.108.74   TCP 54  55710 → 443 [ACK] Seq=267 Ack=2229 Win=131584 Len=0
273 5.365042    172.19.2.30 10.110.108.74   TLSv1.2 60  Change Cipher Spec
274 5.366449    10.110.108.74   172.19.2.30 TCP 56  443 → 55710 [RST] Seq=2229 Win=0 Len=0

Это мой первый опыт взаимной аутентификации, я хотел бы услышать ваш совет и, конечно, поделюсь решением, как только смогу.

Редактировать Я прилагаю тестовый клиент, написанный на java, этот фрагмент кода работает с tomcat 8.0.28, но не с Tomcat 8.5.50

public static void main(String[] args) throws IOException, KeyManagementException, NoSuchAlgorithmException {
        disableSslVerification();
        System.setProperty("javax.net.ssl.keyStoreType", "JKS");
        System.setProperty("javax.net.ssl.trustStoreType", "JKS");
        System.setProperty("javax.net.ssl.keyStore", "path/to/trustStoreFile");
        System.setProperty("javax.net.ssl.trustStore", "path/to/keyStoreFile");
        System.setProperty("javax.net.debug", "all");
        System.setProperty("javax.net.ssl.keyStorePassword", "****");
        System.setProperty("javax.net.ssl.trustStorePassword", "****");

        SSLSocketFactory sslSocketFactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
        URL url = new URL("https://10.110.108.74/webui");
        HttpsURLConnection connection = (HttpsURLConnection)url.openConnection();
        connection.setSSLSocketFactory(sslSocketFactory);

        InputStream in = connection.getInputStream();
        InputStreamReader reader = new InputStreamReader(in);
        BufferedReader bufferedReader = new BufferedReader(reader);

        String str = null;
        while ((str = bufferedReader.readLine()) != null) {
            System.out.println(str);
        }
        System.exit(0);
    }

    private static void disableSslVerification() throws NoSuchAlgorithmException, KeyManagementException {
        // Create a trust manager that does not validate certificate chains
        TrustManager[] trustAllCerts = new TrustManager[] {new X509TrustManager() {
            public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                return null;
            }
            public void checkClientTrusted(X509Certificate[] certs, String authType) {
            }
            public void checkServerTrusted(X509Certificate[] certs, String authType) {
            }
        }
        };

        // Install the all-trusting trust manager
        SSLContext sc = SSLContext.getInstance("SSL");
        sc.init(null, trustAllCerts, new java.security.SecureRandom());
        HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

        // Create all-trusting host name verifier
        HostnameVerifier allHostsValid = new HostnameVerifier() {
            public boolean verify(String hostname, SSLSession session) {
                return true;
            }
        };

        // Install the all-trusting host verifier
        HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
    }

1 Ответ

0 голосов
/ 23 января 2020

ОК, мне удалось понять это. Проблема была в нашем файле склада доверенных сертификатов, сертификат был добавлен с PrivateKeyEntry вместо TrustedCeritciateEntry. Поэтому сервер Tomcat отправил запрос сертификата без нашего внутреннего ЦС.

Отвечая лицам, которые когда-нибудь будут противостоять этому.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...