Java security cert certificateexception - IT Справочник
Llscompany.ru

IT Справочник
20 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Java security cert certificateexception

java.security.cert.CertificateException: No name matching localhost found

Problem

Configured Tomcat to support SSL and deployed this simple hello world web service. And use following client connect to the deployed web service over SSL connection :

It hits “No name matching localhost found” exception :

Solution

This problem and solution is well explained in this article, you can use a Transport Security (SSL) Workaround for your “localhost” development environment.

To fix it, add a javax.net.ssl.HostnameVerifier() method to override the existing hostname verifier like this :

It’s working fine now.

mkyong

Comments

Thank you for the explanation!
The link to the related Oracle article is broken.

hello i am using the above code to call a solr api but its giving the exception “sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target” can you tell me what should i do

I have been facing the same. Please help.

descargar el certificado, Firefox options>Advanced>Certificates>View Certificates>Add exception> url>view>Details>Export guardar como .cer
despues desde cmd abrir cd %java_home%, cd bin ya en bin usar el keytool, e.g.:
C:Program Files (x86)Javajdk1.8.0_111bin>keytool -import -alias xstore -keystore “C:Program Files (x86)Javajdk1.8.0_111jrelibsecuritycacerts” -file C:xauthcertificatexstore.cer

Ahi se agrega el certificado al cacerts y listo, para ver los certificados para asegurar que se haya agregado se puede utilizar el comando
keytool -list -v -keystore “C:Program Files (x86)Javajdk1.8.0_111jrelibsecuritycacerts” > java_cacerts.txt

[…] java.security.cert.CertificateException: No name matching localhost found […]

[…] web service over SSL connection : package com.mkyong.client; import java.net.URL; import… [full post] mkyong Mkyong Dot Com jax-wsweb services 0 0 0 0 1 […]

Hello, Thank you for posting this information. The article like appears to be broken or obsolete. This document http://docs.oracle.com/cd/E19159-01/820-1072/820-1072.pdf explains it on page 75 and may be what was originally pointed to.

java.net.UnknownServiceException: no content-type
at java.net.URLConnection.getContentHandler(URLConnection.java:1209)
at java.net.URLConnection.getContent(URLConnection.java:706)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContent(HttpsURLConnectionImpl.java:426)
at MutualAuthenticationHTTP.doitAll(MutualAuthenticationHTTP.java:100)
at MutualAuthenticationHTTP.main(MutualAuthenticationHTTP.java:75)

hello, I configure a HTTPS webservice adding below constraings to the web.xml: Secure Area /* POST EMPLOYEE

hi.. did you manage to get around with this problem?

Как исправить » java.безопасность.сертификат.CertificateException: нет альтернативных имен субъектов » ошибка?

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

когда я подключаюсь к 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 :

АФАИК, теперь мне нужно

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

если да, то как именно я могу заставить сертификат с шага 1 Работать с IP-адресом ( AAA.BBB.CCC.DDD )?

обновление 1 (23.10.2013 15: 37 MSK): в ответ аналогичный вопрос я прочитал следующее:

если вы не контролируете это сервер, используйте его имя хоста (при условии что существует по крайней мере CN, соответствующий этому имени хоста в существующем сертификат.)

что именно означает» использовать»?

9 ответов:

я исправил проблему, отключив проверки HTTPS, используя представленный подход здесь:

Я поставил следующий код в тег ISomeService класс:

Так как я использую https://AAA.BBB.CCC.DDD:9443/ISomeService только для целей тестирования, это достаточно хорошее решение.

У меня та же проблема и решена с помощью этого кода. Я поставил этот код перед первым вызовом на мои веб-сервисы.

это просто и работает нормально.

здесь является исходным источником.

проверка удостоверения сертификата выполняется в соответствии с запросами клиента.

когда ваш клиент использует https://xxx.xxx.xxx.xxx/something (где xxx.xxx.xxx.xxx — это IP-адрес), Идентификатор сертификата проверяется по этому IP-адресу (теоретически, только с использованием расширения IP SAN).

если Ваш сертификат не имеет IP SAN, но DNS SANs (или если нет DNS SAN, общее имя в теме DN), вы можете заставить это работать, заставив вашего клиента использовать URL с этим именем хоста вместо этого (или a имя хоста, для которого сертификат будет действителен, если существует несколько возможных значений). Например, если у сертификата есть имя www.example.com используйте https://www.example.com/something .

конечно, вам понадобится это имя хоста для разрешения на этот IP-адрес.

кроме того, если есть какие-либо DNS SANs, CN в DN субъекта будет проигнорирован, поэтому используйте имя, которое соответствует одному из DNS SANs в этом случае.

чтобы импортировать сертификат:

  1. извлечь сертификат с сервера, например, openssl s_client -showcerts -connect AAA.BBB.CCC.DDD:9443 > certs.txt Это будет извлекать сертификаты в формате PEM.
  2. преобразуйте сертификат в формат DER, так как это то, что ожидает keytool, например openssl x509 -in certs.txt -out certs.der -outform DER
  3. теперь вы хотите импортировать этот сертификат в системный файл ‘cacert’ по умолчанию. Найдите системный файл по умолчанию ‘cacerts’ для вашей установки Java. Взгляните на как получить расположение cacerts java по умолчанию установка?
  4. импорт сертификатов в этот файл cacerts: sudo keytool -importcert -file certs.der -keystore

пароль cacerts по умолчанию — «changeit».

Если сертификат выдается для полного доменного имени, и вы пытаетесь подключиться по IP-адресу в своем коде Java, то это, вероятно, должно быть исправлено в вашем коде, а не возиться с самим сертификатом. Измените код для подключения по полному доменному имени. Если полное доменное имя не может быть разрешено на компьютере разработчика, просто добавьте его в файл hosts или настройте компьютер с помощью DNS сервер, который может разрешить это полное доменное имя.

моя проблема с получением этой ошибки была решена с помощью полного URL «qatest.ourCompany.com/webService» вместо того, чтобы просто «qatest / webService». Причина заключалась в том, что наш сертификат безопасности имел подстановочный знак, т. е. «*.ourCompany.com как только я ввел полный адрес, исключение исчезло. Надеюсь, это поможет.

вы не можете отключить всю проверку ssl, и поэтому вы можете просто отключить проверку имени хоста через это, что немного менее страшно, чем альтернатива:

Как упоминалось conapart3 SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER теперь устарел, поэтому он может быть удален в более поздней версии, поэтому вы можете быть вынуждены в будущем свернуть свой собственный, хотя я бы все равно сказал, что буду держаться подальше от любых решений, где вся проверка отключена.

я исправил эту проблему правильным образом, добавив имена alt субъекта в сертификат, а не внося какие-либо изменения в код или отключая SSL, в отличие от того, что предлагают здесь другие ответы. Если вы ясно видите, что исключение говорит ,что «Suject alt names отсутствуют», поэтому правильный способ должен добавить их

вышеуказанная ошибка означает, что в вашем файле 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/[email protected]’ -days 365

экспорт открытого ключа (.PEM) файл в формате PKS12. Это предложит вам ввести пароль

создать.JKS из самозаверяющего PEM (Хранилище ключей)

создайте сертификат из хранилища ключей или JKS-файла

, поскольку вышеуказанный сертификат является самоподписанным и не подтверждена центром сертификации, он должен быть добавлен в хранилище доверенных сертификатов(cacerts файл в ниже для Mac, для Windows, узнайте, где установлен JDK является.)

оригинальный ответ написал по этой ссылке здесь.

[Solved] java.security.cert.CertificateException: No subject alternative names present

This blog is about an LDAP SSL connectivity issue which comes after upgrading the Java version

The “java.security.cert.CertificateException: No subject alternative names present” exception is thrown when you are trying to make a secure connection over SSL and the hostname you are trying to connect is not valid when compared to the SSL certificate of the server.

When the server certificate is having Subject Alternative Names (SAN), the requesting home name must match with one of the SANs. If the server’s SSL certificate does not have SANs, then the requesting home name must match with the Common Name (CN) of the certificate.

Note: This blog is about a specific issue which is related to LDAP connectivity after upgrading the Java version. If your issue is not related to LDAP, please follow one of the links below to have a general idea on this error message.

Solve: «No subject alternative DNS name matching» error

I have been working on countless situations on solving SSL related issues, but today I have came across with a new one…

darray.wordpress.com

How to fix javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject…

In this article, we will focus on how to resolve the SSLHandshakeException and possible cause behind it. If you are…

www.littlebigextra.com

Question

Following error blocking up the startup of the WSO2 Identity Server after moving to Java version 1.8.0_181 from an older version.

Answer

The reason this error in java 1.8.0_181 is because this update includes security improvements for LDAP support. “Endpoint identification” has been enabled on LDAPS connections.

According to JDK 8u181 Update Release Notes, endpoint identification algorithms have been enabled by default to improve the robustness of LDAPS (secure LDAP over TLS) connections.

This update applies to all of the following Java versions and their future releases.

There may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.

As a quick fix for this, we can disable endpoint identification by adding the following property after the line “$JAVA_OPTS ” in the /bin/wso2server.sh

But in a production environment, it’s not recommended to disable this feature. So, it’s better to solve by regenerating the LDAP server certificate with the certificate’s SAN or CN matching the hostname of LDAP server configured in primary or secondary userstores which a defined in following locations.

Hope this article would help you to add Subject Alternate Name (SAN) to a self-signed certificate.

For CA-signed certificates, we have to renew the existing certificate with SAN. To add SANs to a certificate, we can generate a Certificate Signing Request (CSR), submit to the Certification Authority and get the certificate renewed. This won’t generate new public/private keys, hence will not cause any issues in the existing deployment.

One other way to avoid this error is to use one of the hostnames which is valid under the LDAP server’s SSL certificate. If your Identity Server node is unable to resolve DNS for that particular domain name, you would add a mapping for that hostname with its IP in the “/etc/hosts” file.

Please leave a comment if you come across any issues or need any clarifications.

How to fix the “java.security.cert.CertificateException: No subject alternative names present” error?

Posted by: admin December 24, 2017 Leave a comment

I have a Java web service client, which consumes a web service via HTTPS.

When I connect to the service URL ( https://AAA.BBB.CCC.DDD:9443/ISomeService ), I get the exception java.security.cert.CertificateException: No subject alternative names present .

To fix it, I first ran openssl s_client -showcerts -connect AAA.BBB.CCC.DDD:9443 > certs.txt and got following content in file certs.txt :

AFAIK, now I need to

  1. extract the part of certs.txt between ——BEGIN CERTIFICATE—— and ——END CERTIFICATE—— ,
  2. modify it so that the certificate name is equal to AAA.BBB.CCC.DDD and
  3. then import the result using keytool -importcert -file fileWithModifiedCertificate (where fileWithModifiedCertificate is the result of operations 1 and 2).

Is this correct?

If so, how exactly can I make the certificate from step 1 work with IP-based adddress ( AAA.BBB.CCC.DDD ) ?

Update 1 (23.10.2013 15:37 MSK): In an answer to a similar question, I read the following:

If you’re not in control of that server, use its host name (provided
that there is at least a CN matching that host name in the existing
cert).

What exactly does “use” mean?

I fixed the problem by disabling HTTPS checks using the approach presented here:

I put following code into the the ISomeService class:

Since I’m using the https://AAA.BBB.CCC.DDD:9443/ISomeService for testing purposes only, it’s a good enough solution.

I’ve the same problem and solved with this code.
I put this code before the first call to my webservices.

It’s simple and works fine.

Here is the original source.

The verification of the certificate identity is performed against what the client requests.

When your client uses https://xxx.xxx.xxx.xxx/something (where xxx.xxx.xxx.xxx is an IP address), the certificate identity is checked against this IP address (in theory, only using an IP SAN extension).

If your certificate has no IP SAN, but DNS SANs (or if no DNS SAN, a Common Name in the Subject DN), you can get this to work by making your client use a URL with that host name instead (or a host name for which the cert would be valid, if there are multiple possible values). For example, if you cert has a name for www.example.com , use https://www.example.com/something .

Of course, you’ll need that host name to resolve to that IP address.

In addition, if there are any DNS SANs, the CN in the Subject DN will be ignored, so use a name that matches one of the DNS SANs in this case.

To import the cert:

  1. Extract the cert from the server, e.g. openssl s_client -showcerts -connect AAA.BBB.CCC.DDD:9443 > certs.txt This will extract certs in PEM format.
  2. Convert the cert into DER format as this is what keytool expects, e.g. openssl x509 -in certs.txt -out certs.der -outform DER
  3. Now you want to import this cert into the system default ‘cacert’ file. Locate the system default ‘cacerts’ file for your Java installation. Take a look at How to obtain the location of cacerts of the default java installation?
  4. Import the certs into that cacerts file: sudo keytool -importcert -file certs.der -keystore

Default cacerts password is ‘changeit’.

If the cert is issued for an FQDN and you’re trying to connect by IP address in your Java code, then this should probably be fixed in your code rather than messing with certificate itself. Change your code to connect by FQDN. If FQDN is not resolvable on your dev machine, simply add it to your hosts file, or configure your machine with DNS server that can resolve this FQDN.

my problem with getting this error was resolved by using the full URL “qatest.ourCompany.com/webService” instead of just “qatest/webService”. Reason was that our security certificate had a wildcard i.e. “*.ourCompany.com”. Once I put in the full address the exception went away. Hope this helps.

I have solved the issue by the following way.

1. Creating a class . The class has some empty implementations

2. Creating a method

  1. Call the disableSSL() method where the exception is thrown. It worked fine.

You may not want to disable all ssl Verificatication and so you can just disable the hostName verification via this which is a bit less scary than the alternative:

Add your IP address in the hosts file.which is in the folder of C:WindowsSystem32driversetc.
Also add IP and Domain Name of the IP address.
example:
aaa.bbb.ccc.ddd [email protected]

Related Posts

java – Can I enable typescript processing only on TS files in wro4j?-Exceptionshub

Questions: I have a legacy app with has old JS code, but I want to utilize TypeScript for some of the newer components. Is it possible to tell wro4j to only apply the rhinoTypeScript preprocessor only.

java – Android studio : Unexpected lock protocol found in lock file . android version 3.5.3 gradle version 5.4.1-Exceptionshub

Questions: I am facing this errors to run the default program of android studio. Tried all of this options but it didn’t work Exception stack trace: org.gradle.internal.service.ServiceCreationEx.

java – Propagation.NEVER vs No Transaction vs Propagation.Required-Exceptionshub

Questions: I have an integration test where I’m trying to understand the difference in behavior for different propagation types (required and never) vs no transaction at all. Here’s my int.

Как исправить ошибку «java.security.cert.CertificateException: нет альтернативных имен объектов»?

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

Когда я подключаюсь к 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 :

AFAIK, теперь мне нужно

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

Правильно ли это?

Если да, то как именно я могу сделать сертификат с шага 1 работать с аддоном на основе IP ( AAA.BBB.CCC.DDD )?

Обновление 1 (23.10.2013 15:37 MSK): В ответе на аналогичный вопрос я прочитал следующее:

Если вы не контролируете этот сервер, используйте его имя хоста (при условии что существует, по меньшей мере, CN, соответствующий этому имени хоста в существующем CERT).

Что именно означает «использование»?

Я исправил проблему, отключив проверки HTTPS, используя представленный ниже подход :

Я поместил следующий код в класс ISomeService :

Поскольку я использую https://AAA.BBB.CCC.DDD:9443/ISomeService только для тестирования, это достаточно хорошее решение.

У меня та же проблема и решена с помощью этого кода. Я помещаю этот код перед первым вызовом своих веб-сервисов.

Это просто и прекрасно работает.

Здесь является исходным источником.

Проверка идентификатора сертификата выполняется против того, что клиент запрашивает.

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

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

Конечно, для этого IP-адреса потребуется имя хоста.

Кроме того, если есть какие-либо DNS-SAN, CN в DN субъекта будет игнорироваться, поэтому в этом случае используйте имя, соответствующее одному из DNS SAN.

Это старый вопрос, но у меня была такая же проблема при переходе с JDK 1.8.0_144 на jdk 1.8.0_191

Мы нашли подсказку в журнале изменений:

мы добавили следующее дополнительное системное свойство, которое помогло в нашем случае решить эту проблему:

Чтобы импортировать сертификат:

  • Извлеките сертификат с сервера, например. openssl s_client -showcerts -connect AAA.BBB.CCC.DDD:9443 > certs.txt Это приведет к извлечению сертификатов в формате PEM.
  • Преобразуйте сертификат в формат DER, поскольку это то, что ожидает keytool, например. openssl x509 -in certs.txt -out certs.der -outform DER
  • Теперь вы хотите импортировать этот сертификат в файл «cacert» по умолчанию. Найдите файл «cacerts» по умолчанию для вашей установки Java. Взгляните на Как получить местоположение cacerts стандартной установки java по умолчанию?
  • Импортировать сертификаты в этот файл cacerts: sudo keytool -importcert -file certs.der -keystore

Пароль по умолчанию cacerts — ‘changeit’.

Если сертификат выдан для полного доменного имени и вы пытаетесь подключиться по IP-адресу в вашем Java-коде, то это, вероятно, должно быть исправлено в вашем коде, а не возиться с самим сертификатом. Измените свой код для подключения по FQDN. Если FQDN не разрешимо на вашем компьютере-разработчике, просто добавьте его в файл hosts или настройте свой компьютер с DNS-сервером, который может разрешить это полное доменное имя.

Я исправил эту проблему правильным образом, добавив альтернативные имена субъекта в сертификат, вместо того, чтобы вносить какие-либо изменения в код или отключать SSL в отличие от других ответов, предложенных здесь. Если вы ясно видите, что исключение говорит: «Suject alt names отсутствует», значит, правильный способ их добавления —

Вышеуказанная ошибка означает, что в вашем 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/[email protected]’ -days 365

Экспортируйте файл с открытым ключом (.pem) в формат PKS12. Это предложит вам ввести пароль

Создайте a.JKS из самоподписанного PEM (Keystore)

Сгенерируйте сертификат из хранилища ключей или JKS файла

Поскольку вышеуказанный сертификат является самоподписанным и не проверен CA, его необходимо добавить в Truststore (файл Cacerts в расположении ниже для MAC, для Windows, узнайте, где установлен ваш JDK.)

Оригинальный ответ размещен по этой ссылке здесь.

Читать еще:  Wrong data type java lang illegalargumentexception
Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector