Ошибка java security cert

Contrary to the accepted answer you do not need a custom trust manager, you need to fix your server configuration!

I hit the same problem while connecting to an Apache server with an incorrectly installed dynadot/alphassl certificate. I’m connecting using HttpsUrlConnection (Java/Android), which was throwing —

javax.net.ssl.SSLHandshakeException: 
  java.security.cert.CertPathValidatorException: 
    Trust anchor for certification path not found.

The actual problem is a server misconfiguration — test it with http://www.digicert.com/help/ or similar, and it will even tell you the solution:

«The certificate is not signed by a trusted authority (checking against Mozilla’s root store). If you bought the certificate from a trusted authority, you probably just need to install one or more Intermediate certificates. Contact your certificate provider for assistance doing this for your server platform.»

You can also check the certificate with openssl:

openssl s_client -debug -connect www.thedomaintocheck.com:443

You’ll probably see:

Verify return code: 21 (unable to verify the first certificate)

and, earlier in the output:

depth=0 OU = Domain Control Validated, CN = www.thedomaintocheck.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, CN = www.thedomaintocheck.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, CN = www.thedomaintocheck.com
verify error:num=21:unable to verify the first certificate`

The certificate chain will only contain 1 element (your certificate):

Certificate chain
 0 s:/OU=Domain Control Validated/CN=www.thedomaintocheck.com
  i:/O=AlphaSSL/CN=AlphaSSL CA - G2

… but should reference the signing authorities in a chain back to one which is trusted by Android (Verisign, GlobalSign, etc):

Certificate chain
 0 s:/OU=Domain Control Validated/CN=www.thedomaintocheck.com
   i:/O=AlphaSSL/CN=AlphaSSL CA - G2
 1 s:/O=AlphaSSL/CN=AlphaSSL CA - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
 2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA

Instructions (and the intermediate certificates) for configuring your server are usually provided by the authority that issued your certificate, for example: http://www.alphassl.com/support/install-root-certificate.html

After installing the intermediate certificates provided by my certificate issuer I now have no errors when connecting using HttpsUrlConnection.

Comments

Error Message

When trying to sign in to access a secured ArcGIS Server feature service on ArcGIS Collector, the following error may be returned:

Error:  
"java.security.cert.CertPathValidatorException: Trust anchor for certification path not found"

When working with ArcGIS Collector, there is the flexibility to work with secured services from ArcGIS Enterprise deployments. The secured feature services can be added to ArcGIS Online with the option to ‘Store credentials’ checked, or configured to prompt for credentials when opened on the mobile device.

When working with secured layers added as operational layers without storing credentials, ArcGIS Collector displays a warning, ‘Secured layers. You need to sign in to access some of the layers in this map.’

Clicking ‘View’, opens the Layer List, where the Layer name is marked with a triangular warning sign, ‘Sign in required’. Normally, a prompt to enter a username and password to authenticate access to the layer is displayed. However in some cases, the option may not be present.

ArcGIS Collector (iOS) does not return any error, however, ArcGIS Collector (Android) displays the error, ‘java.security.cert.CertPathValidatorException: Trust anchor for certification path not found’.

Cause

The underlying issue is the SSL Settings on the Web Adaptor configured with the ArcGIS Server site. This setting can be enabled on Internet Information Services (IIS) Manager to require the client to be identified before gaining access to any resource.

Solution or Workaround

1. Identify the Web Adaptor machine name. Open ArcGIS Server Manager.
2. Click the Site tab.
3. Click the Web Adaptor tab and note the machine name from the list of adaptors.

1. Log in to the Web Adaptor machine for ArcGIS Server.
2. Launch Internet Information Services (IIS) Manager and browse to the Web Adaptor name under the default website.
3. Click SSL Settings and under Client certificates, change the setting to Ignore.  Apply the changes.

7 Flares

Twitter


1

Facebook


0

Google+


5

LinkedIn


1

Email


—

Filament.io

7 Flares

×

How to Fix the exception ” java.security.cert.CertificateException: No name matching localhost found”, when client uses URL with “localhost” as host name to access some secure service over HTTPS? In this article we will check the root cause of the issue and will try two different solutions two fix the same.
There are other similar issues related the SSL certificates. One of the common situation is the missing certificate in trust store. In that case you may see the following error message.

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

See the following article to read more about the above error and its solution.

PKIX Path Building Failed (Validation) : sun.security.validator.ValidatorException

When Do You Encounter the Error : java.security.cert.CertificateException: No name matching localhost found?

When you use self signed certificate for services such as secure web service and try to access the service over HTTPS from a client using “localhost”, you may encounter the error “java.security.cert.CertificateException: No name matching localhost found”.
The error can also be something like “java.security.cert.CertificateException: No name matching <hostname> found”, where, the “hostname” can be anything.

…..
Caused by: javax.net.ssl.SSLHandshakeException: 
    java.security.cert.CertificateException: No name matching localhost found
	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181)
	......
Caused by: java.security.cert.CertificateException: No name matching localhost found
	at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
	at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
…….

Root Cause of the Exception: java.security.cert.CertificateException: No name matching <host> found

At run-time, Java check host name against the names specified in a digital certificate as required for TLS and LDAP.
So if you are using for example, https://localhost:8443/MyService/.. , the runtime will check if the certificate allows use of the given DNS name, in this case “localhost”. This matching is performed using the matching rules specified by RFC2459.

As per the java doc, “If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.”
Also “If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.)”

The above points indicate that, the certificate CN (Common Name) should be the same as host name in the URL. If the CN in the certificate is not the same as the host name, you will get the error “java.security.cert.CertificateException: No name matching <the_host_name_used> found”, where , “the_host_name_used” is the host name you used as part of the URL in your client application.

How to solve the error “java.security.cert.CertificateException: No name matching localhost found”?

Method 1: Change the Certificate CN name

The first step is to verify the CN (Common Name) in the certificate. Please not that, you cannot change the CN in an already created certificate. This is because, a certificate is designed specifically so that this data can’t be modified after its creation. It is part of the certificate.

CN=localhost, OU=home, O=home, L=city,ST=state, C=in

So you need to create a new certificate with the hostname as “localhost” or any other hostname you want to use. Example is given below. You can use the java keytool tool to create your self-signed certificate with the “localhost” CN.

F:myservicesrc>keytool -genkey -alias serverkey -keypass nosecret -keyalg RSA -sigalg SHA1withRSA -keystore server.keystore -storepass nostoresecret
What is your first and last name?
  [Unknown]:  localhost
What is the name of your organizational unit?
  [Unknown]:  globinch ws
What is the name of your organization?
  [Unknown]:  globinch
What is the name of your City or Locality?
  [Unknown]:  Bangalore
What is the name of your State or Province?
  [Unknown]:  KAR
What is the two-letter country code for this unit?
  [Unknown]:  IN
Is CN=localhost, OU=globinch ws, O=globinch, L=Bangalore, ST=KAR, C=IN correct?
  [no]:  yes

That’s all. You need to apply this certificate and setup the web server. Now if you use endpoint such as https://localhost:8443/MyService/..” ,the java security run-time will accept it.

Implement the verify() method of HostnameVerifier

HostnameVerifier is the base interface for hostname verification. As per java doc “During handshaking, if the URL’s hostname and the server’s identification hostname mismatch, the verification mechanism can call back to implementers of this interface to determine if this connection should be allowed”.
These callbacks are used when the default rules for URL hostname verification fail.
The HttpsURLConnection class uses HostnameVerifier and SSLSocketFactory. You can set the HostnameVerifier using the setDefaultHostnameVerifier(setDefaultHostnameVerifier) method. See example below.

javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(
    new javax.net.ssl.HostnameVerifier(){
 
        public boolean verify(String hostname,
                javax.net.ssl.SSLSession sslSession) {
            if (hostname.equals("localhost")) {
                return true;
            }
            return false;
        }
    });

So during handshaking, if the URL’s hostname and the server’s identification hostname mismatch, it will invoke the above verify implementation. The above code returns “true” for hostname “localhost”, and the connection is allowed.

References:

• HostnameChecker.java
• HostnameVerifier.java
• HttpsURLConnection.java

Incoming search terms:

• HowtoFix:java security cert CertificateException:Nonamematchinglocalhostfound
• java security cert CertificateException
• java security cert certificateexception: no name matching localhost found
• java security cert CertificateException: No subject alternative names presen
• java security cert CertificateException: No subject alternative names present
• https://java globinch com/enterprise-java/security/fix-java-security-certificate-exception-no-matching-localhost-found/
• ccilweb
• CertificateException

7 Flares

Twitter


1

Facebook


0

Google+


5

LinkedIn


1

Email


—

Filament.io

7 Flares

×