Як виправити помилку "java.security.cert.CertificateException: Альтернативних імен предмета немає"?

У мене є клієнт веб-служби Java, який користується веб-сервісом через HTTPS.

import javax.xml.ws.Service;

@WebServiceClient(name = "ISomeService", targetNamespace = "http://tempuri.org/", wsdlLocation = "...")
public class ISomeService
    extends Service
{

    public ISomeService() {
        super(__getWsdlLocation(), ISOMESERVICE_QNAME);
    }

Коли я підключаюсь до URL-адреси сервісу ( https://AAA.BBB.CCC.DDD:9443/ISomeService), я отримую виняток java.security.cert.CertificateException: No subject alternative names present.

Щоб виправити це, я спершу запустив openssl s_client -showcerts -connect AAA.BBB.CCC.DDD:9443 > certs.txtта отримав у файлі такий вміст certs.txt:

CONNECTED(00000003)
---
Certificate chain
 0 s:/CN=someSubdomain.someorganisation.com
   i:/CN=someSubdomain.someorganisation.com
-----BEGIN CERTIFICATE-----
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=someSubdomain.someorganisation.com
issuer=/CN=someSubdomain.someorganisation.com
---
No client certificate CA names sent
---
SSL handshake has read 489 bytes and written 236 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 512 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5            
    Session-ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Session-ID-ctx:                 
    Master-Key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key-Arg   : None
    Start Time: 1382521838
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

AFAIK, зараз мені потрібно

1. витягти частину certs.txtміж -----BEGIN CERTIFICATE-----і -----END CERTIFICATE-----,
2. змінити його так, щоб ім'я сертифіката було рівним AAA.BBB.CCC.DDDта
3. потім імпортуйте результат, використовуючи keytool -importcert -file fileWithModifiedCertificate(де fileWithModifiedCertificateрезультат 1 та 2).

Це правильно?

Якщо так, то як саме я можу змусити сертифікат з кроку 1 працювати з адресною адресою ( AAA.BBB.CCC.DDD)?

Оновлення 1 (23.10.2013 15:37 MSK): У відповіді на подібне запитання я прочитав наступне:

Якщо ви не контролюєте цей сервер, використовуйте його ім'я хоста (за умови, що принаймні CN відповідає цьому імені хоста в існуючому сертифіката).

Що саме означає "використання"?

Я вирішив проблему, відключивши перевірки HTTPS, використовуючи представлений тут підхід :

Я кладу наступний код у ISomeServiceклас:

static {
    disableSslVerification();
}

private static void disableSslVerification() {
    try
    {
        // 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);
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
    } catch (KeyManagementException e) {
        e.printStackTrace();
    }
}

Оскільки я використовую лише https://AAA.BBB.CCC.DDD:9443/ISomeServiceтестувальні цілі, це досить хороше рішення.

У мене така ж проблема і вирішена з цим кодом. Я ставлю цей код до першого дзвінка до своїх веб-сервісів.

javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(
new javax.net.ssl.HostnameVerifier(){

    public boolean verify(String hostname,
            javax.net.ssl.SSLSession sslSession) {
        return hostname.equals("localhost");
    }
});

Це просто і працює чудово.

Ось першоджерело.

Це старе запитання, але у мене була та сама проблема при переході від JDK 1.8.0_144 до jdk 1.8.0_191

Ми знайшли підказку в журналі змін:

Журнал змін

ми додали наступну додаткову властивість системи, яка допомогла в нашому випадку вирішити цю проблему:

-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true

Перевірка посвідчення сертифікату проводиться відповідно до того, що вимагає клієнт.

Коли ваш клієнт використовує https://xxx.xxx.xxx.xxx/something(де xxx.xxx.xxx.xxxIP-адресу), ідентифікація сертифікату перевіряється на цю IP-адресу (теоретично, лише за допомогою розширення IP SAN).

Якщо у вашому сертифікаті немає IP SAN, але DNS SAN (або якщо DNS SAN, загальне ім’я в суб’єктному DN), ви можете змусити це працювати, якщо змусити клієнта використовувати URL-адресу з цим ім'ям хоста (або ім'ям хоста для якого cert було б дійсним, якщо існує кілька можливих значень). Наприклад, якщо у вас є назва www.example.com, використовуйте https://www.example.com/something.

Звичайно, вам знадобиться це ім'я хоста, щоб дозволити цю IP-адресу.

Крім того, якщо є будь-які DNS SAN, CN в Subject DN буде ігноровано, тому використовуйте ім'я, яке відповідає одному з DNS SAN в цьому випадку.

Щоб імпортувати сертифікат:

1. Витягніть cert з сервера, наприклад, openssl s_client -showcerts -connect AAA.BBB.CCC.DDD:9443 > certs.txtце вилучить certs у форматі PEM.
2. Перетворіть cert у формат DER, оскільки це очікує keytool, наприклад openssl x509 -in certs.txt -out certs.der -outform DER
3. Тепер ви хочете імпортувати цей сертифікат у системний файл "cacert" за замовчуванням. Знайдіть системний файл "cacerts" за замовчуванням для вашої установки Java. Погляньте на те, як отримати місце розташування кокетки за замовчуванням Java-установки?
4. Імпорт certs у цей файл cacerts: sudo keytool -importcert -file certs.der -keystore <path-to-cacerts>Пароль cacerts за замовчуванням - 'changeit'.

Якщо сертифікат виданий для FQDN, і ви намагаєтесь підключитися за IP-адресою у вашому коді Java, це, мабуть, має бути зафіксовано у вашому коді, а не возитися з самим сертифікатом. Змініть код для підключення за допомогою FQDN. Якщо FQDN не вирішується на вашому комп'ютері розробників, просто додайте його у свій хост-файл або налаштуйте свою машину за допомогою сервера DNS, який може вирішити цю FQDN.

Я вирішив цю проблему правильним шляхом, додавши тематичні імена alt у сертифікат, а не вносячи будь-які зміни в код або відключивши SSL, на відміну від інших відповідей. Якщо ви чітко бачите, що виняток говорить, що "Імена альт-предметів відсутні", тому правильним способом має бути їх додавання

Перегляньте це посилання, щоб зрозуміти покроково .

Вищеописана помилка означає, що у вашому файлі JKS відсутній необхідний домен, на який ви намагаєтеся отримати доступ до програми. Вам потрібно буде використовувати Open SSL та ключовий інструмент для додавання декількох доменів

1. Скопіюйте openssl.cnf у поточний каталог
2. echo '[ subject_alt_name ]' >> openssl.cnf
3. echo 'subjectAltName = DNS:example.mydomain1.com, DNS:example.mydomain2.com, DNS:example.mydomain3.com, DNS: localhost'>> openssl.cnf
4. openssl req -x509 -nodes -newkey rsa:2048 -config openssl.cnf -extensions subject_alt_name -keyout private.key -out self-signed.pem -subj '/C=gb/ST=edinburgh/L=edinburgh/O=mygroup/OU=servicing/CN=www.example.com/emailAddress=postmaster@example.com' -days 365

5. Експортуйте файл відкритого ключа (.pem) у формат PKS12. Це підкаже вам пароль

   openssl pkcs12 -export -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in
   self-signed.pem -inkey private.key -name myalias -out keystore.p12

6. Створіть a.JKS з самопідписаного PEM (Keystore)

   keytool -importkeystore -destkeystore keystore.jks -deststoretype PKCS12 -srcstoretype PKCS12 -srckeystore keystore.p12

7. Створіть сертифікат зверху з файлу Keystore або JKS

   keytool -export -keystore keystore.jks -alias myalias -file selfsigned.crt

8. Оскільки вищевказаний сертифікат є самопідписаним і не підтверджений CA, його потрібно додати в Truststore (файл Cacerts в нижньому місці для MAC, для Windows, дізнайтеся, де встановлений ваш JDK.)

   sudo keytool -importcert -file selfsigned.crt -alias myalias -keystore /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/security/cacerts

Оригінальна відповідь розміщена за цим посиланням тут .

Ви, можливо, не хочете вимкнути всю перевірку ssl, і тому ви можете просто відключити перевірку хост-імені через це, що трохи менше страшно, ніж альтернатива:

HttpsURLConnection.setDefaultHostnameVerifier(
    SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

[EDIT]

Як згадується conapart3 SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER, тепер застаріла, тому вона може бути видалена в більш пізній версії, тому в майбутньому вас можуть змусити прокласти свій власний, хоча я все одно скажу, що відмовляться від будь-яких рішень, де вся перевірка вимкнена.

мою проблему з отриманням цієї помилки було вирішено за допомогою повної URL-адреси "qatest.ourCompany.com/webService" замість просто "qatest / webService". Причина полягала в тому, що у нашому сертифікаті безпеки є майна, тобто "* .ourCompany.com". Як тільки я виклав повну адресу, виняток пішов. Сподіваюся, це допомагає.

Відповіли на це вже на https://stackoverflow.com/a/53491151/1909708 .

Це не вдається, оскільки ні загальна назва сертифіката ( CNу сертифікації Subject), ні будь-яке альтернативне ім’я ( Subject Alternative Nameу сертифікаті) не відповідають цільовому імені хоста чи IP-адреси.

Наприклад, від JVM при спробі підключення до IP-адреси ( WW.XX.YY.ZZ), а не до імені DNS ( https://stackoverflow.com ) з'єднання HTTPS не вдасться, тому що сертифікат, що зберігається у сховищі Java, cacertsочікує загального імені (або альтернативне ім'я сертифіката, наприклад stackexchange.com або * .stackoverflow.com тощо), щоб відповідати цільовій адресі.

Перевірте: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#HostnameVerifier

    HttpsURLConnection urlConnection = (HttpsURLConnection) new URL("https://WW.XX.YY.ZZ/api/verify").openConnection();
    urlConnection.setSSLSocketFactory(socketFactory());
    urlConnection.setDoOutput(true);
    urlConnection.setRequestMethod("GET");
    urlConnection.setUseCaches(false);
    urlConnection.setHostnameVerifier(new HostnameVerifier() {
        @Override
        public boolean verify(String hostname, SSLSession sslSession) {
            return true;
        }
    });
    urlConnection.getOutputStream();

Вище передано реалізований HostnameVerifierоб'єкт, який завжди повертає true:

new HostnameVerifier() {
        @Override
        public boolean verify(String hostname, SSLSession sslSession) {
            return true;
        }
    }

Для весняного черевика RestTemplate:

• додайте org.apache.httpcomponents.httpcoreзалежність

• використання NoopHostnameVerifierдля заводу SSL:

  SSLContext sslContext = new SSLContextBuilder()
          .loadTrustMaterial(new URL("file:pathToServerKeyStore"), storePassword)
  //        .loadKeyMaterial(new URL("file:pathToClientKeyStore"), storePassword, storePassword)
          .build();
  SSLConnectionSocketFactory socketFactory = new SSLConnectionSocketFactory(sslContext, NoopHostnameVerifier.INSTANCE);
  CloseableHttpClient client = HttpClients.custom().setSSLSocketFactory(socketFactory).build();
  HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(client);
  RestTemplate restTemplate = new RestTemplate(factory);

Я дійшов до цього питання після того, як отримав таке саме повідомлення про помилку. Однак у моєму випадку у нас було дві URL-адреси з різними субдоменами ( http://example1.xxx.com/someservice та http://example2.yyy.com/someservice ), які були спрямовані на один і той же сервер. Цей сервер мав лише один сертифікат підстановки для домену * .xxx.com. Під час використання послуги через другий домен знайдений сертифікат (* .xxx.com) не відповідає запитуваному домену (* .yyy.com) і виникає помилка.

У цьому випадку ми не повинні намагатися виправити таке повідомлення про помилки, знизивши безпеку SSL, але слід перевірити сервер та сертифікати на ньому.

public class RESTfulClientSSL {

    static TrustManager[] trustAllCerts = new TrustManager[]{new X509TrustManager() {
        @Override
        public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
            // TODO Auto-generated method stub
        }

        @Override
        public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
            // TODO Auto-generated method stub
        }

        @Override
        public X509Certificate[] getAcceptedIssuers() {
            // TODO Auto-generated method stub
            return null;
        }
    }};

    public class NullHostNameVerifier implements HostnameVerifier {
        /*
         * (non-Javadoc)
         *
         * @see javax.net.ssl.HostnameVerifier#verify(java.lang.String,
         * javax.net.ssl.SSLSession)
         */
        @Override
        public boolean verify(String arg0, SSLSession arg1) {
            // TODO Auto-generated method stub
            return true;
        }
    }

    public static void main(String[] args) {

        HttpURLConnection connection = null;
        try {

            HttpsURLConnection.setDefaultHostnameVerifier(new RESTfulwalkthroughCer().new NullHostNameVerifier());
            SSLContext sc = SSLContext.getInstance("SSL");
            sc.init(null, trustAllCerts, new SecureRandom());
            HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());


            String uriString = "https://172.20.20.12:9443/rest/hr/exposed/service";
            URL url = new URL(uriString);
            connection = (HttpURLConnection) url.openConnection();
            connection.setRequestMethod("GET");
            //connection.setRequestMethod("POST");

            BASE64Encoder encoder = new BASE64Encoder();
            String username = "admin";
            String password = "admin";
            String encodedCredential = encoder.encode((username + ":" + password).getBytes());
            connection.setRequestProperty("Authorization", "Basic " + encodedCredential);

            connection.connect();
            BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
            int responseCode = connection.getResponseCode();
            if (responseCode == HttpURLConnection.HTTP_OK) {
                StringBuffer stringBuffer = new StringBuffer();
                String line = "";
                while ((line = reader.readLine()) != null) {
                    stringBuffer.append(line);
                }
                String content = stringBuffer.toString();
                System.out.println(content);
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (connection != null) {
                connection.disconnect();
            }
        }
    }
}

Я переживав 2-х напрямковий SSL у Springboot. Я зробив усі правильні сервісні налаштування сервера tomcat і сервісного абонента RestTemplate. але я отримував помилку як "java.security.cert.CertificateException: альтернативних назв предметів немає"

Після перегляду рішень я знайшов, що JVM потребує цього сертифіката, інакше він дає помилку рукостискання.

Тепер, як додати це до JVM.

перейдіть до файлу jre / lib / security / cacerts. нам потрібно додати наш файл сертифіката сервера до цього файлу кесерів jvm.

Команда для додавання серверного файлу до файлу cacerts через командний рядок у Windows.

C: \ програмні файли \ Java \ jdk1.8.0_191 \ jre \ lib \ безпека> keytool -import -noprompt -trustcacerts -alias sslserver -file E: \ spring_cloud_sachin \ ssl_keys \ sslserver.cer-cacerts-зберігання

Перевірте, чи встановлено серверну версію чи ні:

C: \ Програмні файли \ Java \ jdk1.8.0_191 \ jre \ lib \ security> keytool -list -keystere cacerts

ви можете побачити список встановлених сертифікатів:

для більш детальної інформації: https://sachin4java.blogspot.com/2019/08/javasecuritycertcertificateexception-no.html

додайте хост-запис із ip, що відповідає CN у сертифікаті

CN = someSubdomain.someorganisation.com

тепер оновіть ip на ім'я CN, де ви намагаєтесь отримати доступ до URL-адреси.

Це працювало для мене.

Цей код буде працювати як шарм і використовувати об’єкт restTemple для решти коду.

  RestTemplate restTemplate = new RestTemplate();   
  TrustStrategy acceptingTrustStrategy = new TrustStrategy() {
            @Override
            public boolean isTrusted(java.security.cert.X509Certificate[] x509Certificates, String s) {
                return true;
            }

        };

        SSLContext sslContext = null;
        try {
            sslContext = org.apache.http.ssl.SSLContexts.custom().loadTrustMaterial(null, acceptingTrustStrategy)
                    .build();
        } catch (NoSuchAlgorithmException e) {
            e.printStackTrace();
        } catch (KeyManagementException e) {
            e.printStackTrace();
        } catch (KeyStoreException e) {
            e.printStackTrace();
        }
        SSLConnectionSocketFactory csf = new SSLConnectionSocketFactory(sslContext, new NoopHostnameVerifier());
        CloseableHttpClient httpClient = HttpClients.custom().setSSLSocketFactory(csf).build();
        HttpComponentsClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory();
        requestFactory.setHttpClient(httpClient);

        restTemplate.setRequestFactory(requestFactory);
}

Якщо у вас є сертифікат як із CN, так і з суб'єктними альтернативними іменами (SAN), якщо ви робите свій запит на основі вмісту CN, то цей конкретний вміст також повинен бути присутнім під SAN, інакше він не вийде із помилкою, про яку йдеться.

У моєму випадку у CN було щось, у SAN щось інше. Мені довелося скористатися SAN URL, і тоді це спрацювало чудово.

Додайте свою IP-адресу у файл хостів, який знаходиться у папці C: \ Windows \ System32 \ driver \ тощо. Також додайте IP та доменне ім’я IP-адреси. приклад: aaa.bbb.ccc.ddd abc@def.com

Я вирішив питання таким чином.

1. Створення класу. У класі є кілька порожніх реалізацій

class MyTrustManager implements X509TrustManager {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
    return null;
}

public void checkClientTrusted(X509Certificate[] certs, String authType) {
}

public void checkServerTrusted(X509Certificate[] certs, String authType) {
}

@Override
public void checkClientTrusted(java.security.cert.X509Certificate[] paramArrayOfX509Certificate, String paramString)
        throws CertificateException {
    // TODO Auto-generated method stub

}

@Override
public void checkServerTrusted(java.security.cert.X509Certificate[] paramArrayOfX509Certificate, String paramString)
        throws CertificateException {
    // TODO Auto-generated method stub

}

2. Створення методу

private static void disableSSL() {
    try {
        TrustManager[] trustAllCerts = new TrustManager[] { new MyTrustManager() };

        // Install the all-trusting trust manager
        SSLContext sc = SSLContext.getInstance("SSL");
        sc.init(null, trustAllCerts, new java.security.SecureRandom());
        HostnameVerifier allHostsValid = new HostnameVerifier() {
            public boolean verify(String hostname, SSLSession session) {
                return true;
            }
        };
        HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
        HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
    } catch (Exception e) {
        e.printStackTrace();
    }
}

3. Виклик методу disabledSSL (), де викидається виняток. Це добре працювало.