SSL Certificat de Vérification : javax.net.le protocole ssl.SSLHandshakeException

Je suis en train d'appeler un HTTPS API REST par Jersey Client. Et sur le cours de développement, je tombe sur l'erreur suivante :

Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching mvn.signify.abc.com found
    at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:149)
    at com.sun.jersey.api.client.Client.handle(Client.java:648)
    at com.sun.jersey.api.client.WebResource.handle(WebResource.java:670)
    at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
    at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:503)
    at com.lftechnology.sbworkbench.utility.utils.PingFederateUtility.main(PingFederateUtility.java:32)
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching mvn.signify.abc.com found

Donc je l'ai googlé un peu et trouvé des tonnes de solution pour elle , qui fonctionne réellement.

Ils sont dans différents domaine, mais ils ont une solution commune pour travailler.

Scénario

Je suis actuellement en utilisant un auto créé certificat auto-signé dans un environnement de développement. Et par conséquent, il est lié à la question.

Question

La solution mentionnée ci-dessus se concentrer sur sauter /permettant à tous les certificats à vérifier.

Mais quand je la déplace dans l'environnement de production , puis-je avoir accès à la validation de la signature de Certificat de source digne de confiance.

Sont donc ces solution toute aide quand je bouge à la production?
C'est OK pour ignorer la vérification SSL ?
Quels sont les autre façon de parvenir à une solution commune pour
à la fois le développement et l'environnement de production?

P. S

La solution que j'ai utilisé était ,

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();
}

qui je puis en-coopérer avec Jersey pour le faire fonctionner. Et c'est génial de travailler.

Donc , le Question de nouveau. Est-ce une solution viable à être utilisé dans un environnement de Production?
Cependant, vous ne voulez pas modifier le retour des entités, c'est beaucoup mieux pour extraire les entités en mode lecture seule. Cela permet à Hibernate de jeter les associés détaché de l'état qui est utilisé par la sale mécanisme de contrôle afin de détecter l'état de l'entité modifications. De plus, en lecture seule entités sont ignorées pendant le rinçage.

"C'est OK pour ignorer la vérification SSL ?" - plutôt pas.. ou n'avez-vous pas ici sur les Pommes GOTO FAIL?!
"Donc , la Question à nouveau. La solution est-elle viable à être utilisé dans un environnement de Production?" - non, il n'est pas. Son irresponsabilité et la négligence.

OriginalL'auteur Runcorn | 2014-08-01

13

Je suis actuellement en utilisant un auto créé certificat auto-signé dans
environnement de développement. ... javax.net.le protocole ssl.SSLHandshakeException:
java.de sécurité.cert.CertificateException: Aucun nom correspondant
dev.ppc.lftechnology.com trouvé

Il semble que le certificat auto-signé est incorrect.

Ci-dessous est la OpenSSL CONF fichier que j'utilise pour créer les certificats auto-signés et des demandes de certificat à utiliser au cours du test. Enregistrer en tant que example-com.conf. Modifier les DNS sous les noms de [ alternate_names ] en fonction de vos goûts. Vous pouvez même mettre localhost, localhost.localdomain et 127.0.0.1 là pour les tests.

Si vous souhaitez créer un certificat auto-signé, puis utilisez:
```
openssl req -config example-com.conf -new -x509 -newkey rsa:2048 \
    -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem
```
Si vous souhaitez créer une demande de signature de l'entreprise (RSE) qui sera signé par une autorité de confiance, puis utilisez:
```
openssl req -config example-com.conf -new -newkey rsa:2048 \
    -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
```
La différence entre un certificat auto-signé et une demande de signature est le -x509 option. Avec -x509 présent, un certificat auto-signé est créé. L'absence de -x509 signifie une demande est créée.

Si vous souhaitez imprimer votre certificat auto-signé ou demande à voir ce qui est réellement en elle, puis utiliser:
```
openssl x509 -in example-com.cert.pem -text -noout
openssl req -in example-com.req.pem -text -noout
```
Si vous voulez tester le serveur, puis utilisez s_client:
```
openssl s_client -connect <server>:<port> -CAfile <trust-anchor.pem>
```
La commande ci-dessus devrait se terminer avec un message similaire à Verify OK (0). Si vous ne recevez pas Verify OK (0), puis réparer votre banc d'essai. Une fois OpenSSL est terminée avec succès, alors que devient votre point de départ.
```
[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_extensions
x509_extensions     = cert_extensions
string_mask         = utf8only
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US
stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName            = Locality Name (eg, city)
localityName_default        = New York
organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC
# Use a friendly name here. Its presented to the user.
#   The server's DNS name show up in Subject Alternate Names. Plus, 
#   DNS names here is deprecated by both IETF and CA/Browser Forums.
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company
emailAddress            = Email Address
emailAddress_default        = test@example.com
[ cert_extensions ]
subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
# extendedKeyUsage  = serverAuth
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"
[ req_extensions ]
subjectKeyIdentifier        = hash
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
# extendedKeyUsage  = serverAuth
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"
[ alternate_names ]
DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com
# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1
```
C'est OK pour ignorer la vérification SSL ?

Pas. C'est très irresponsable. Si vous n'allez pas utiliser PKIX correctement, alors pourquoi l'utiliser?

Ce qui vient à l'esprit: La Plupart de Code Dangereux dans le Monde: la Validation des Certificats SSL Non Logiciel de navigation.
```
HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
};
```
Son mieux pour charger votre certificat auto-signé dans un magasin de clés (ou la charge de votre autorité de certification privée), et ensuite de le passer SSLContext.init. Ensuite, tout fonctionne comme prévu, et il n'y a pas besoin de faire confiance à tout ou retour true de verify.

Bruno et EJP avoir beaucoup de réponses couvrant ce sujet.

Quelles sont les autres autre façon de parvenir à une solution commune à la fois le développement et l'environnement de production?

L'utilisation d'un bien formé certificat lié à une racine de confiance.

Pour les tests, vous pouvez créer un certificat auto-signé. Ou, créer une demande de certificat et de le faire signer par votre autorité de certification interne dans une infrastructure à clé publique. Dans ce cas, vous devez faire confiance à votre certificat auto-signé ou faire confiance à votre autorité de certification interne.

De la production, vous pouvez utiliser un certificat signé par l'un des membres du CA Zoo afin que d'autres personnes en dehors de l'organisation des fiducies de trop. StartCom et CACert offrir gratuitement les certificats de Classe 1.

Classe 1 les certificats sont généralement de domaine validé et ne permettent pas de cartes sauvages. Alors que la Classe 1 est délivré gratuitement, ils se chargent de révocation parce que c'est là le coût des mensonges.

Si vous avez besoin d'une wild card, alors vous aurez généralement à l'achat d'un de Classe 2 ou supérieure.

Merci @sauteur avec slalom c'est un jeu génial de réponse. J'ai mis à jour ma question, un peu au sujet de la solution je l'ai mentionné.
Merci pour tes précieux renseignements @sauteur avec slalom.
salut @sauteur avec slalom il fonctionne très bien pour localhost {DNS}, Quand je donne l'adresse ip locale comme 192.168.1.56 il n'est pas de travail.Merci de m'aider
Ajouter quelque chose de semblable à DNS.5 = 192.168.1.56. Si sa ne fonctionne toujours pas, alors que son rapport aux navigateurs. Mais je n'ai pas été en mesure de traquer ce qu'est exactement les navigateurs trouver offensive sur les adresses IP (par rapport à des noms DNS). Ryan Sleevi de Google a expliqué qu'il est Commentaires sur draft-ietf-websec-clé-pinning, mais je n'ai pas digéré encore.
Navigateur n'est pas de donner un quelconque problème, Jersey est donnant problème

OriginalL'auteur jww

@sauteur avec slalom, à juste titre, répond à la question

C'est OK pour ignorer la vérification SSL? Pas de. C'est très irresponsable.

Toutefois, dans certains cas, vous ne pouvez pas contrôler le serveur en question pour être en mesure d'installer un certificat valide. Si le serveur appartient à quelqu'un d'autre, et que vous faites confiance que serveur, une meilleure solution est d'utiliser une "liste blanche" pour valider les certificats que pour des serveurs de confiance, sinon normal d'utilisation de la validation.

public static class WhitelistHostnameVerifier implements HostnameVerifier {
private static final HostnameVerifier defaultHostnameVerifier = HttpsURLConnection.getDefaultHostnameVerifier();
private Set<String> trustedHosts;
public WhitelistHostnameVerifier(Set<String> trustedHosts) {
this.trustedHosts = trustedHosts;
}
@Override
public boolean verify(String hostname, SSLSession session) {
if (trustedHosts.contains(hostname)) {
return true;
} else {
return defaultHostnameVerifier.verify(hostname, session);
}
}
}

Et l'installer une fois:

HttpsURLConnection.setDefaultHostnameVerifier(
new WhitelistHostnameVerifier(Sets.newHashSet("trustedhost.mydomain.com")));

Si vous allez désactiver un contrôle de sécurité, ne pas le faire à l'échelle mondiale...

OriginalL'auteur Steve Jones

Il y a une étiquette logiciel bug avec le Java Keytool pour la version Java 1.7.0_60-b19, lors de la création d'un certificat auto-signé. Voir ces instructions pour référence.

https://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-using-java-keytool.html

Quand il vous demande "Quel est votre prénom et de votre nom?", au lieu de taper votre nom, vous devez entrer un nom commun, ou (nom de domaine complet de votre serveur).

[root@localhost ~]# keytool -genkey -keyalg RSA -alias myalias -keystore keystore.jks -storepass XXXXXX -validity 360 -keysize 2048
What is your first and last name?
[Unknown]:  Angus MacGyver
What is the name of your organizational unit?
[Unknown]:  My Department
What is the name of your organization?
[Unknown]:  My Company
What is the name of your City or Locality?
[Unknown]:  My City
What is the name of your State or Province?
[Unknown]:  My State
What is the two-letter country code for this unit?
[Unknown]:  US
Is CN=Angus MacGyver, OU=My Department, O=My Company, L=My City, ST=My State, C=US correct?
[no]:  yes
Enter key password for <selfsigned>
(RETURN if same as keystore password):XXXXXX
Re-enter new password:XXXXXX

Vous pouvez vérifier si le "CN" (nom commun) attribut est défini correctement par l'appel de cette:

[root@localhost ~]# keytool -v -list -keystore keystore.jks

Trouver la version de Java:

[root@localhost ~]# java -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing)

OriginalL'auteur MacGyver

Vous devez vous connecter pour publier un commentaire.