Fabric Version: v2.2.4
Fabric Gateway Version: v2.2.0
Currently, I am not using Fabric CA and docker. Instead, I am using OpenSSL to generate my own certificates. There is no problem using command line to join channel or invoke chaincode with TLS enabled (Server TLS).
However, when I try to invoke my chaincode using Fabric Gateway Java SDK with TLS, the peer shows:
2021-10-20 23:53:51.571 EDT [core.comm] ServerHandshake -> ERRO 411 Server TLS handshake failed in 731.664253ms with error remote error: tls: internal error server=PeerServer remoteaddress=127.0.0.1:48920
2021-10-20 23:53:51.648 EDT [core.comm] ServerHandshake -> ERRO 412 Server TLS handshake failed in 17.623962ms with error remote error: tls: internal error server=PeerServer remoteaddress=127.0.0.1:48924
2021-10-20 23:53:52.389 EDT [core.comm] ServerHandshake -> ERRO 413 Server TLS handshake failed in 31.834126ms with error remote error: tls: internal error server=PeerServer remoteaddress=127.0.0.1:48928
2021-10-20 23:53:53.013 EDT [core.comm] ServerHandshake -> ERRO 414 Server TLS handshake failed in 20.97883ms with error remote error: tls: internal error server=PeerServer remoteaddress=127.0.0.1:48932
2021-10-20 23:53:53.453 EDT [core.comm] ServerHandshake -> ERRO 415 Server TLS handshake failed in 27.840631ms with error remote error: tls: internal error server=PeerServer remoteaddress=127.0.0.1:48936
if I disable the TLS, the chaincode can be invoked and queried but it shows an error message and display the certificate of the peer:
04:45:56.020 [main] ERROR org.hyperledger.fabric.sdk.security.CryptoPrimitives - Cannot
validate certificate. Error is: Path does not chain with any of the trust anchors
Certificate[
[
Version: V3
Subject: CN=peer-telecom, OU=peer, O=peer0.telecom.com, ST=Wilayah Persekutuan Kuala Lumpur, C=MY
Signature Algorithm: SHA256withECDSA, OID = 1.2.840.10045.4.3.2
Key: Sun EC public key, 256 bits
public x coord: 63258922835963897769642318382353579773301130246303245867091942631050654760639
public y coord: 17014436126955018341557373411142402131278326611630973049174140241981148702177
parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
Validity: [From: Mon Oct 18 04:30:10 EDT 2021,
To: Tue Oct 18 04:30:10 EDT 2022]
Issuer: CN=hyperledger-telecom, O=ica.hyperledger.telecom.com, ST=Wilayah Persekutuan Kuala Lumpur, C=MY
SerialNumber: [ 1000]
Certificate Extensions: 4
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 70 2B 57 B5 7C 6A 38 DE AB 6F DD 7E C4 63 FE 39 p+W..j8..o...c.9
0010: 54 22 D9 F9 T"..
]
]
[2]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
]
[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
]
[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 62 C2 4A FB 13 54 44 DF 15 AB 2B 09 78 4F 79 4A b.J..TD...+.xOyJ
0010: CB 37 1D D7 .7..
]
]
]
Algorithm: [SHA256withECDSA]
Signature:
0000: 30 44 02 20 2D 20 15 9D 53 D4 DE EF 56 0D E6 6D 0D. - ..S...V..m
0010: 04 DA 99 F8 0C AC D5 A7 87 66 51 04 23 A0 4D C2 .........fQ.#.M.
0020: C8 98 95 5C 02 20 5C A5 5A 2D 19 43 FA E8 C0 E1 ...\. \.Z-.C....
0030: 49 4E C0 DF C9 59 F8 10 34 D6 94 05 51 38 E9 17 IN...Y..4...Q8..
0040: C5 F1 20 1F 0C EC .. ...
]
Java Application code:
package org.example.contract;
import java.io.IOException;
import java.io.Reader;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.nio.file.Files;
import java.util.concurrent.TimeoutException;
import java.security.InvalidKeyException;
import java.security.PrivateKey;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import org.hyperledger.fabric.gateway.Identities;
import org.hyperledger.fabric.gateway.Identity;
import org.hyperledger.fabric.gateway.Contract;
import org.hyperledger.fabric.gateway.ContractException;
import org.hyperledger.fabric.gateway.Gateway;
import org.hyperledger.fabric.gateway.Network;
import org.hyperledger.fabric.gateway.Wallet;
import org.hyperledger.fabric.gateway.Wallets;
public class Sample {
X509Certificate[] clientCert = null;
PrivateKey clientKey = null;
private static X509Certificate readX509Certificate(final Path certificatePath) throws IOException, CertificateException {
try (Reader certificateReader = Files.newBufferedReader(certificatePath, StandardCharsets.UTF_8)) {
return Identities.readX509Certificate(certificateReader);
}
}
private static PrivateKey getPrivateKey(final Path privateKeyPath) throws IOException, InvalidKeyException {
try (Reader privateKeyReader = Files.newBufferedReader(privateKeyPath, StandardCharsets.UTF_8)) {
return Identities.readPrivateKey(privateKeyReader);
}
}
public static void main(String[] args) throws IOException {
// Load an existing wallet holding identities used to access the network.
// A wallet stores a collection of identities
Path walletPath = Paths.get(".", "wallet");
Wallet wallet = Wallets.newFileSystemWallet(walletPath);
try {
Path credentialPath = Paths.get("/root","fabric","localtls","crypto-config", "peerOrganizations",
"org1.telecom.com", "users", "Admin#org1.telecom.com", "msp");
System.out.println("credentialPath: " + credentialPath.toString());
Path certificatePath = credentialPath.resolve(Paths.get("signcerts",
"Admin#org1.telecom.com-cert.pem"));
System.out.println("certificatePem: " + certificatePath.toString());
Path privateKeyPath = credentialPath.resolve(Paths.get("keystore",
"Admin#telecom.com.key"));
X509Certificate certificate = readX509Certificate(certificatePath);
PrivateKey privateKey = getPrivateKey(privateKeyPath);
Identity identity = Identities.newX509Identity("Org1MSP", certificate, privateKey);
String identityLabel = "Admin#org1.telecom.com";
wallet.put(identityLabel, identity);
System.out.println("Write wallet info into " + walletPath.toString() + " successfully.");
} catch (IOException | CertificateException | InvalidKeyException e) {
System.err.println("Error adding to wallet");
e.printStackTrace();
}
// Path to a common connection profile describing the network.
Path networkConfigFile = Paths.get("/root","fabric","localtls","connection.yaml");
String userName = "Admin#org1.telecom.com";
// Configure the gateway connection used to access the network.,
Gateway.Builder builder = Gateway.createBuilder()
.identity(wallet, userName)
.networkConfig(networkConfigFile);
// Create a gateway connection
try (Gateway gateway = builder.connect()) {
// Obtain a smart contract deployed on the network.
Network network = gateway.getNetwork("mychannel");
Contract contract = network.getContract("chaincode");
// Submit transactions that store state to the ledger.
byte[] createCarResult = contract.createTransaction("createMyAsset")
.submit("CAR", "Honda");
System.out.println(new String(createCarResult, StandardCharsets.UTF_8));
byte[] queryCar = contract.submitTransaction("readMyAsset", "CAR");
System.out.println(new String(queryCar, StandardCharsets.UTF_8));
} catch (ContractException | TimeoutException | InterruptedException e) {
e.printStackTrace();
}
}
}
connection.yaml:
name: "Network-Config-Test"
description: "The network used in the integration tests"
version: 1.0.0
client:
organization: telecom
organizations:
telecom:
mspid: Org1MSP
peers:
- peer0.org1.telecom.com
#adminPrivateKey:
#path: '/root/fabric/localtls/crypto-config/peerOrganizations/org1.telecom.com/users/Admin#org1.telecom.com/msp/keystore/Admin#telecom.com.key'
#signedCert:
#path: '/root/fabric/localtls/crypto-config/peerOrganizations/org1.telecom.com/users/Admin#org1.telecom.com/msp/signcerts/Admin#org1.telecom.com-cert.pem'
orderers:
orderer.example.com:
url: grpcs://localhost:6050
#client:
#keyfile: '/root/fabric/localtls/crypto-config/peerOrganizations/org1.telecom.com/users/Admin#org1.telecom.com/tls/client-o.key'
#certfile: '/root/fabric/localtls/crypto-config/peerOrganizations/org1.telecom.com/users/Admin#org1.telecom.com/tls/client-o.crt'
grpcOptions:
hostnameOverride: orderer.example.com
grpc-max-send-message-length: 15
grpc.keepalive_time_ms: 360000
grpc.keepalive_timeout_ms: 180000
negotiationType: TLS
sslProvider: openSSL
tlsCACerts:
path: /root/fabric/localtls/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/tls/ca.crt
peers:
peer0.org1.telecom.com:
url: grpcs://localhost:7051
#client:
#keyfile: '/root/fabric/localtls/crypto-config/peerOrganizations/org1.telecom.com/users/Admin#org1.telecom.com/tls/client.key'
#certfile: '/root/fabric/localtls/crypto-config/peerOrganizations/org1.telecom.com/users/Admin#org1.telecom.com/tls/client.crt'
grpcOptions:
ssl-target-name-override: peer0.org1.telecom.com
grpc.http2.keepalive_time: 15
hostnameOverride: peer0.org1.telecom.com
negotiationType: TLS
sslProvider: openSSL
tlsCACerts:
path: /root/fabric/localtls/crypto-config/peerOrganizations/org1.telecom.com/peers/peer0.org1.telecom.com/tls/ca.crt
What am I missing? Any answer is welcomed!
Update 1.0
These are the certificates generated by using openSSL, they work when I use command line (I ommitted the hf thing in the Subject Alternative Name, not sure is it important for the application to work?):
The tlscacert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1f:a5:9f:1a:01:ed:c7:3d:30:ca:27:b6:79:9c:82:10:b8:94:84:23
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = MY, ST = Wilayah Persekutuan Kuala Lumpur, L = Kuala Lumpur, O = rca.verisign.com, CN = tls-verisign
Validity
Not Before: Oct 21 03:11:13 2021 GMT
Not After : Oct 19 03:11:13 2031 GMT
Subject: C = MY, ST = Wilayah Persekutuan Kuala Lumpur, L = Kuala Lumpur, O = rca.verisign.com, CN = tls-verisign
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:34:b5:ac:a3:42:8c:d4:17:97:ca:16:d5:2f:7a:
00:32:bf:fd:dd:02:8a:33:28:ed:c0:53:5d:e0:42:
79:0d:08:43:1c:22:83:1e:f0:71:91:08:d6:c3:ec:
eb:ac:9c:56:00:da:e8:08:cf:ad:4c:b3:46:e7:e1:
39:1c:5f:bf:fc
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
EB:7B:8E:23:26:A7:17:3D:E0:0B:8D:B4:6E:6C:5D:D5:EE:EF:80:AF
X509v3 Authority Key Identifier:
keyid:EB:7B:8E:23:26:A7:17:3D:E0:0B:8D:B4:6E:6C:5D:D5:EE:EF:80:AF
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:63:40:88:2d:c8:51:e5:42:2b:d3:98:60:6f:1e:
3c:d2:f6:59:48:bb:0c:7c:10:b6:28:27:86:20:58:35:0b:19:
02:21:00:c7:87:df:79:75:21:8d:bf:bc:be:aa:c9:44:53:b5:
b4:32:4d:06:2b:a0:05:eb:38:b7:9f:3d:71:80:17:77:69
The Peer TLS cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4097 (0x1001)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = MY, ST = Wilayah Persekutuan Kuala Lumpur, L = Kuala Lumpur, O = rca.verisign.com, CN = tls-verisign
Validity
Not Before: Oct 21 03:11:13 2021 GMT
Not After : Oct 21 03:11:13 2022 GMT
Subject: C = MY, ST = Wilayah Persekutuan Kuala Lumpur, O = tls.peer.telecom.com, CN = tls-peer-telecom
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:76:c2:e9:94:10:03:2c:3b:2d:90:56:e8:b5:30:
bf:67:f6:b5:b8:9c:73:cd:28:b3:f2:f7:21:e9:f7:
6c:66:38:a9:e8:7c:b0:ea:67:fb:f7:db:72:29:9d:
aa:56:20:92:ab:b1:e5:53:2a:a1:19:0b:0c:8b:65:
36:fe:98:aa:e1
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Key Identifier:
08:9D:B8:81:4B:39:0D:B1:D4:BD:EC:49:E5:AC:BA:FB:F1:7A:58:51
X509v3 Authority Key Identifier:
keyid:EB:7B:8E:23:26:A7:17:3D:E0:0B:8D:B4:6E:6C:5D:D5:EE:EF:80:AF
X509v3 Subject Alternative Name:
IP Address:127.0.0.1
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:c0:d7:26:b4:e9:30:08:b5:37:46:66:0f:fb:
b6:36:22:04:5f:78:ab:ae:ff:7f:48:e0:7b:ff:e8:f0:88:b4:
e5:02:21:00:86:64:ec:c8:9b:b4:06:b5:3d:d3:c1:54:4f:d2:
a2:bb:1a:e1:a7:e7:84:28:9a:ef:ac:db:ab:65:95:0d:10:2d
The only thing I am missing in the cert is:
1.2.3.4.5.6.7.8.1:
{"attrs":{"hf.Affiliation":"","hf.EnrollmentID":"peer0","hf.Type":"peer"}}
Is this only being used by the Fabric CA? Or it is a must to include?
Fabric TLS certificates are very fiddly. For instance, we've found several cases where the peer and chaincode will accept a malformed cert, but the gateway client refuses to connect using the same certificate. What is probably happening is that you have a problem with the openssl generated cert, but the peer is too lax to report the error. (It also doesn't help that the client TLS libraries simply disconnect, without reporting on the root failure during the handshake.)
In the example above, the cert output shows some differences in PathLen and KeyUsage attributes that differ from what are normally generated by a Fabric CA.
Here are some ideas and techniques that we've found to be useful in debugging TLS handshake issues with the gateway / client SDKs. Try to use these techniques to close any gaps between your certs and the reference certs generated by the Fabric CAs:
Use the Fabric CAs. Even if you plan to generate a certificate chain using OpenSSL and an external authority, you can use the Fabric CAs to generate TLS enrollments and certificates, and compare the reference certs against what you have built up with OpenSSL.
Use curl, or other TLS-enabled clients to help verify the correctness of a certificate. In many cases the errors output by an independent client are directly applicable to the failed TLS handshake when connecting the fabric client.
Use the test-network-k8s system as a reference for setting up the TLS and CA infrastructure. In addition to a "push button" test network, this will provide CA endpoints that can be used to generate reference enrollments / certificates for study.
Inspect the certificates generated by the Fabric CAs, and compare against your hand-crafted certs. For example, here is a certificate dump from a TLS cert generated with the Kube test network - make sure your OpenSSL certs have the same, or similar feature sets and attributes.
$ openssl x509 -in /tmp/ca-cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
4c:63:74:d5:99:29:ce:e0:b6:28:a2:b5:a4:0e:a0:c1:f3:e9:a9:d5
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=North Carolina, O=Hyperledger, OU=Fabric, CN=fabric-ca-server
Validity
Not Before: Oct 21 10:36:00 2021 GMT
Not After : Oct 17 10:36:00 2036 GMT
Subject: C=US, ST=North Carolina, O=Hyperledger, OU=Fabric, CN=fabric-ca-server
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:53:f4:ad:e6:6b:4c:75:7e:4a:6d:6e:cd:73:b0:
81:a8:d7:d7:55:c0:fd:22:92:15:fc:2d:20:44:c6:
ec:55:c9:cc:88:3a:14:09:77:e5:4f:4b:b8:98:ee:
71:09:da:e6:f8:7c:f7:39:fa:41:fc:f3:a2:fe:a4:
1e:34:ec:a9:b5
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:1
X509v3 Subject Key Identifier:
AB:AF:85:A3:D3:2E:9A:A9:03:49:F5:5C:30:32:2B:92:EC:92:B3:D0
X509v3 Subject Alternative Name:
IP Address:127.0.0.1
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:bf:cc:c1:d2:29:b1:04:3f:55:31:c6:b7:69:
ca:72:12:d7:67:55:14:cd:23:f7:75:16:6c:b1:63:7f:e6:9c:
24:02:20:5d:ff:e3:7e:84:22:d3:f3:52:bd:96:fa:dc:2d:94:
2f:6b:a3:bc:ab:3e:b3:87:10:fd:30:51:a2:4a:ca:ce:b4
-----BEGIN CERTIFICATE-----
MIICKDCCAc6gAwIBAgIUTGN01ZkpzuC2KKK1pA6gwfPpqdUwCgYIKoZIzj0EAwIw
aDELMAkGA1UEBhMCVVMxFzAVBgNVBAgTDk5vcnRoIENhcm9saW5hMRQwEgYDVQQK
EwtIeXBlcmxlZGdlcjEPMA0GA1UECxMGRmFicmljMRkwFwYDVQQDExBmYWJyaWMt
Y2Etc2VydmVyMB4XDTIxMTAyMTEwMzYwMFoXDTM2MTAxNzEwMzYwMFowaDELMAkG
A1UEBhMCVVMxFzAVBgNVBAgTDk5vcnRoIENhcm9saW5hMRQwEgYDVQQKEwtIeXBl
cmxlZGdlcjEPMA0GA1UECxMGRmFicmljMRkwFwYDVQQDExBmYWJyaWMtY2Etc2Vy
dmVyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEU/St5mtMdX5KbW7Nc7CBqNfX
VcD9IpIV/C0gRMbsVcnMiDoUCXflT0u4mO5xCdrm+Hz3OfpB/POi/qQeNOyptaNW
MFQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYE
FKuvhaPTLpqpA0n1XDAyK5LskrPQMA8GA1UdEQQIMAaHBH8AAAEwCgYIKoZIzj0E
AwIDSAAwRQIhAL/MwdIpsQQ/VTHGt2nKchLXZ1UUzSP3dRZssWN/5pwkAiBd/+N+
hCLT81K9lvrcLZQva6O8qz6zhxD9MFGiSsrOtA==
-----END CERTIFICATE-----
Related
I'm having problems connecting to mongodb with ssl, first all I could connect mongodb with an application java without any problem, but when I connect from server application like Jetty with spring boot I can't connect to mongodb. Curiously I could connect to mongodb with eclipse.
Java code to connect:
String trustStorePath = "/path/ssl_keystore_mongodb";
String trustStorePassword = "somePassword";
String uri = "mongodb://admin:password#domain1:31251,domain2:31251/my-db?authSource=admin&ssl=true";
System.setProperty("javax.net.ssl.trustStore", trustStorePath);
System.setProperty("javax.net.ssl.trustStorePassword", trustStorePassword);
MongoClient mongoClient = new MongoClient(new MongoClientURI(uri);
Code works fine without server application but with server application the output is:
com.mongodb.MongoSocketWriteException: Exception sending message}, caused by {javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 169.47.75.121 found}, caused by {java.security.cert.CertificateException: No subject alternative names matching IP address 169.47.75.121 found}}, {address=sl-us-south-1-portal.14.dblayer.com:31251, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketWriteException: Exception sending message}, caused by {javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address xxx.xx.xx.xxx found}, caused by {java.security.cert.CertificateException: No subject alternative names matching IP address xxx.xx.xx.xxx found}}]
My ssl certificate:
Owner: CN=kbengtsson#efact.pe-4178203cf8de512257f4efeebac75b34
Issuer: CN=kbengtsson#efact.pe-4178203cf8de512257f4efeebac75b34
Serial number: 5a4d0994
Valid from: Wed Jan 03 11:49:24 PET 2018 until: Sun Jan 03 11:00:00 PET 2038
Certificate fingerprints:
MD5: 94:EC:B1:49:BB:56:B9:4B:E3:FC:D3:FE:74:C8:FA:D8
SHA1: EA:95:CC:45:43:E4:DA:12:EA:6C:D6:3F:8D:D3:0A:E6:C5:62:B3:96
SHA256: 9F:A9:AA:84:83:33:BB:B7:39:50:3A:8B:11:3D:B6:07:CD:7E:6D:C3:29:F8:9C:21:4C:B5:47:65:86:19:E7:73
Signature algorithm name: SHA512withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 61 71 23 3E FF 31 E2 D1 C0 D0 23 F6 4A 1F 0E 55 aq#>.1....#.J..U
0010: B3 28 1D 69 .(.i
]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 61 71 23 3E FF 31 E2 D1 C0 D0 23 F6 4A 1F 0E 55 aq#>.1....#.J..U
0010: B3 28 1D 69 .(.i
]
]
The certificate is provided by IBM.
How can I solve this issue?
This Exception says that you're waiting for a certificate with a CN (or SAN) containing an IP instead of an FQDN. For any reason you're requesting https://169.47.75.121 instead of https://sl-us-south-1-portal.14.dblayer.com
How to solve ? By letting the DNS doing its job. Check all of your config files and code, if they contain this IP remove it. Check also your hosts files on each computer, add references where needed. If you still can't find why this happens, another method is to disable the certificate validation as explained in the doc Host name verification
My colleague set up a (Bluemix) secure gateway using mutual auth for our project to use. He tested it with Ruby and CURL and it works fine. but when configuring my Liberty server to use it, I am running in to many issues.
I used the instructions found here.
Basically...
To create a key store for the client, enter the following command. In the following example, key.p.12 is created.
openssl pkcs12 -export -in "[client]_cert.pem" -inkey "[client]_key" -out "sg_key.p12" -name BmxCliCert -noiter –nomaciter –password pass:<password>
Which creates a PKCS12 store. (I use this in server.xml below)
I then added the certs into my keystore.
I then changed my server.xml to have a trust store as referenced in my
<ldapRegistry baseDN="o=ibm.com" host="bluepages.ibm.com" id="bluepages" ignoreCase="true"
ldapType="IBM Tivoli Directory Server" port="636" realm="w3" sslEnabled="true" sslRef="SSLSettings">
<idsFilters groupFilter="(&(cn=%v)(objectclass=groupOfUniqueNames))" groupIdMap="*:cn" groupMemberIdMap="groupOfUniqueNames:uniquemember" userFilter="(&(emailAddress=%v)(objectclass=person))" userIdMap="*:emailAddress"/>
</ldapRegistry>
<ssl id="SSLSettings" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore"/>
<keyStore id="defaultKeyStore" password="xxxxxx"
location="${server.output.dir}/resources/security/key.jks"/>
<keyStore id="defaultTrustStore"
location="${server.output.dir}/resources/security/sg_key.p12"
type="PKCS12" password="xxxxxx" />
Here's issue #1
When I add the trust store, I can no longer authenticate via my LDAP server. It just says invalid user or password. I remove the trust store.. and I can authenticate again. So adding the truststore has some type of affect.
Issue #2. When I remove my LDAP server and just use basic user registry... I can login in.. but when I try and use the secure gateway, I get..
[err] javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
I have imported the certificate from the secure gateway so not sure why I get this?
So two issues.. Using a truststore.. I can no longer auth via LDAP... and second.. cannot connect to the secure gateway even after importing all certs...
Anyone had success using Bluemix with a Secure Gateway (Mutual Auth) from Java?
Requested info (edited)
Enter Import Password:
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
friendlyName: portal
localKeyID: 5F A0 D5 5D 68 C5 39 65 7D 24 D7 78 9B CD 7D 01 FB 1B 00 6D
subject=/ST=NC/C=US/L=RTP/O=IBM Corporation/OU=SWG/CN=*.integration.ibmcloud.com
issuer=/ST=NC/C=US/L=RTP/O=IBM Corporation/OU=SWG/CN=*.integration.ibmcloud.com
-----BEGIN CERTIFICATE-----
INFO
4Q==
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
friendlyName: portal
localKeyID: 5F A0 D5 5D 68 C5 39 65 7D 24 D7 78 9B CD 7D 01 FB 1B 00 6D
Key Attributes: <No Attributes>
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----BEGIN ENCRYPTED PRIVATE KEY-----
INFO
-----END ENCRYPTED PRIVATE KEY-----
Finally got this to work.
previous code..
. . . .
connection = (HttpsURLConnection) url.openConnection();
Where url was the URL of the Secure Gateway.
Added before this...
KeyStore clientStore = KeyStore.getInstance("PKCS12");
clientStore.load(new FileInputStream(KEY_STORE_PATH), "xxxxxx".toCharArray());
KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(clientStore, "xxxxxx".toCharArray());
KeyManager[] kms = kmf.getKeyManagers();
KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream(TRUST_STORE_PATH), "xxxxxx".toCharArray());
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(trustStore);
TrustManager[] tms = tmf.getTrustManagers();
SSLContext sslContext = null;
sslContext = SSLContext.getInstance("TLS");
sslContext.init(kms, tms, new SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());`
connection = (HttpsURLConnection) url.openConnection();
Now it works... tx
Some good info in this thread.. LINK
I'm trying to send HTTPS request from my Java EE program to the host that requires certificate authentication. I have a proper keystore file, truststore with imported CA, the listing of both shows that certificates are inside.
But I receive the following error:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: KeyUsage does not allow digital signatures
at ...
...
Caused by: sun.security.validator.ValidatorException: KeyUsage does not allow digital signatures
at sun.security.validator.EndEntityChecker.checkTLSServer(EndEntityChecker.java:270)
at sun.security.validator.EndEntityChecker.check(EndEntityChecker.java:141)
at sun.security.validator.Validator.validate(Validator.java:264)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1319)
... 29 more
Viewing the certificate contents in the part of Extensions I see the following:
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 33 87 72 1D 09 2F DF FF 1A A7 D1 C0 E1 CF C5 FA 3.r../..........
0010: A4 19 54 2E ..T.
]
]
#2: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL client
]
#3: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 74 9F 43 07 CC 75 FA D3 D0 13 0F 65 36 CC 4A 9A t.C..u.....e6.J.
0010: E0 8E 9C 52 ...R
]
]
#4: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://test.az:7447/Test%20CA.crl]
]]
#5: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
]
So my certificate does contain KeyUsage [ DigitalSignature ]
The code snippet of the place throwing the exception looks like the following:
private final static int KU_SIGNATURE = 0;
...
private void checkTLSServer(X509Certificate cert, String parameter)
throws CertificateException {
Set<String> exts = getCriticalExtensions(cert);
...
} else if (KU_SERVER_SIGNATURE.contains(parameter)) {
if (checkKeyUsage(cert, KU_SIGNATURE) == false) {
throw new ValidatorException
("KeyUsage does not allow digital signatures",
ValidatorException.T_EE_EXTENSIONS, cert);
}
}
...
}
and checkKeyUsage function:
private boolean checkKeyUsage(X509Certificate cert, int bit)
throws CertificateException {
boolean[] keyUsage = cert.getKeyUsage();
if (keyUsage == null) {
return true;
}
return (keyUsage.length > bit) && keyUsage[bit];
}
it fails in return (keyUsage.length > bit) && keyUsage[bit];
The question is why the result of above expression = false? When bit = 0 and cert.getKeyUsage() must return an array of boolean [true, false, false, false, false, false, false, false, false]
The error actually comes from verifying the server's certificate. That certificate has a key usage section that doesn't include a digitalSignature bit.
Some cipher suites require the digital signature bit, specifically Diffie-Hellman key exchange (DHE_RSA and ECDHE_RSA). You may be able to avoid this error by avoiding those cipher types. Otherwise the server certificate needs to support it.
this error happened also to me and while the answer of #Chris D is correct I thought about giving you a way to overcome this issue.
We are in a situation where our Java application has to talk with a server through HTTPS. If we are able to tune this server's TLS we can solve the issue.
Basically we need to disable all the ciphers based on Diffie Hellman on the HTTPS server. You need to exclude all ciphers which contain DH.
In case of Haproxy I used these directives:
global
ssl-default-bind-ciphers AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
In case of a Java HTTPS server I've set this env var:
SERVER_SSL_CIPHERS=TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA
which will then be translated to the Java property server.ssl.ciphers
If you want to force some ciphers on the client-side, this SO question might be what you're looking for Java - How can I disable a TLS cipher for only some protocols using JVM Config?
Confirming that this behavior is still the same for the latest JRE version (19).
There seems to be another way how to avoid the problem (beside the one mentioned by Chris D). It looks like when a trust anchor is present inside the truststore java does not trigger the checks responsible for throwing the described exception and blindly trust to the server's certificate.
The related code can be saw here:
https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/validator/Validator.java#L259
This means importing the server's certificate directly into the java's truststore resolves the issue.
I am in the process of configuring WebSphere MQ and SSL and then connect to it using Java and JMS/JNDI. The version I use is 6.0.1.1. Here are the steps I followed but I can't make it run because I get an SSL exception.
Step 1: Configure SSL for MQ Series
export JAVA_HOME=/opt/mqm/ssl
cd /var/mqm/qmgrs/MYQMGR/ssl
# Set up the key repository
gsk7cmd -keydb -create -db keydb.kdb -pw password -type cms -expire 1500 -stash
# Create a self-signed personal certificate
gsk7cmd -cert -create -db keydb.kdb -pw password -label ibmwebspheremqmyqmgr -dn "CN=My Queue Manager,O=My Company,C=UK" -size 1024 -x509version 3 -expire 365
# Export your personal certificate
gsk7cmd -cert -extract -db filename -pw password -label ibmwebspheremqmyqmgr -target myqmgr.cert.arm -format ascii
Step 2: Configure SSL for Java
# Generate the private/public key pair
# keypass option is the password to protect the private key
# storepass option is the password to protect the keystore
keytool -genkey -keystore keystore -storepass storepass -keypass keypass -dname "cn=My Java Client,O=My Company,C=UK" -alias ClientMQ -keyalg RSA -keysize 2048
# Export the public key if you need 2-way authentification
keytool -export -keystore keystore -storepass storepass -alias ClientMQ -file client.cer
# Import MQ public certificate into the truststore
# storepass option is the password to protect the keystore
keytool -import -keystore truststore -storepass trustpass -keypass keypass -alias ibmwebspheremqmyqmgr -file myqmgr.cert.arm
Step 3: Configure MQ Bindings
The SSL.CHANNEL has been create with the command: DEFINE CHANNEL(SSL.CHANNEL) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCIPH(RC4_SHA_US) SSLCAUTH(OPTIONAL) DESCR('Channel using SSL')
JMSAdmin.config
INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
PROVIDER_URL=file:///opt/mqm/java/bin/JNDI
SECURITY_AUTHENTICATION=none
cd /opt/mqm/java/bin
. setjmsenv
./JMSAdmin -v -cfg JMSAdmin.config
DEFINE QCF(QCF_NAME) SYNCPOINTALLGETS(YES) HOSTNAME(HOST) PORT(1414) TRANSPORT(client) QMANAGER(MYQMGR) CHANNEL(SSL.CHANNEL) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_SHA)
DEFINE Q(MYQNAME) QMANAGER(MYQMGR) QUEUE(LOCALQUEUE)
Step 4: Figure out why I get the exception
When I ran my Java app I get the following exception when calling connectionFactory.createQueueConnection();:
javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for 'xxxx:xxxxx'
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2397
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
Here is the SSL trace:
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: c:\home\doc\jsse\truststore
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=My Queue Manager,O=My Company,C=UK
Issuer: CN=My Queue Manager,O=My Company,C=UK
Algorithm: RSA; Serial number: 0x5072a61a
Valid from Sun Oct 07 12:08:26 CEST 2012 until Tue Oct 08 12:08:26 CEST 2013
trigger seeding of SecureRandom
done seeding SecureRandom
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1349707178 bytes = { 204, 18, 167, 43, 13, 107, 252, 221, 191, 41, 25, 59, 207, 92, 67, 219, 251, 104, 195, 209, 7, 129, 104, 171, 139, 47, 163, 71 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_SHA]
Compression Methods: { 0 }
***
[write] MD5 and SHA1 hashes: len = 45
0000: 01 00 00 29 03 01 50 73 E6 AA CC 12 A7 2B 0D 6B ...)..Ps.....+.k
0010: FC DD BF 29 19 3B CF 5C 43 DB FB 68 C3 D1 07 81 ...).;.\C..h....
0020: 68 AB 8B 2F A3 47 00 00 02 00 05 01 00 h../.G.......
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 45
[write] MD5 and SHA1 hashes: len = 44
0000: 01 03 01 00 03 00 00 00 20 00 00 05 50 73 E6 AA ........ ...Ps..
0010: CC 12 A7 2B 0D 6B FC DD BF 29 19 3B CF 5C 43 DB ...+.k...).;.\C.
0020: FB 68 C3 D1 07 81 68 AB 8B 2F A3 47 .h....h../.G
Thread pool thread #0, WRITE: SSLv2 client hello message, length = 44
[Raw write]: length = 46
0000: 80 2C 01 03 01 00 03 00 00 00 20 00 00 05 50 73 .,........ ...Ps
0010: E6 AA CC 12 A7 2B 0D 6B FC DD BF 29 19 3B CF 5C .....+.k...).;.\
0020: 43 DB FB 68 C3 D1 07 81 68 AB 8B 2F A3 47 C..h....h../.G
Thread pool thread #0, received EOFException: error
Thread pool thread #0, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
Thread pool thread #0, SEND TLSv1 ALERT: fatal, description = handshake_failure
Thread pool thread #0, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 28 ......(
Thread pool thread #0, called closeSocket()
Finalizer, called close()
Finalizer, called closeInternal(true)
On MQ side:
AMQ9660: SSL key repository: password stash file absent or unusable.
EXPLANATION:
The SSL key repository cannot be used because MQ cannot obtain a password to
access it. Reasons giving rise to this error include:
(a) the key database file and password stash file are not present in the
location configured for the key repository,
(b) the key database file exists in the correct place but that no password
stash file has been created for it,
(c) the files are present in the correct place but the userid under which MQ is
running does not have permission to read them,
(d) one or both of the files are corrupt.
But none of them applies to me.
ls -ltr /var/mqm/qmgrs/MYQMGR/ssl/
total 235
-rw-r--r-- 1 mqm mqm 129 Oct 8 12:00 keydb.sth
-rw-r--r-- 1 mqm mqm 115080 Oct 8 12:08 keydb.kdb
-rw-r--r-- 1 mqm mqm 80 Oct 8 12:08 keydb.rdb
-rw-r--r-- 1 mqm mqm 80 Oct 8 12:08 keydb.crl
Stupid mistake: alter qmgr SSLKEYR('/var/mqm/qmgrs/MYQMGR/ssl/keydb') fixes the issue.
I am trying to build a custom HTTPS Server in Java (6) using the built in class com.sun.net.httpserver.HttpsServer. It works fine until I require client authentication. At that point it fails with the following exception in the SSL debug on the server.
sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL client
I am using certificates issued by our internal CA which is used for all applications internal to us. I checked the certificate details and found that type was "SSL Server" (details quoted below). Since our policy is to use a "SSL Server" type for all internal applications, it is difficult to change the cerificate. Since I want to use a Server certificate for Client, I don't believe this is a security issue.
What I am looking for is a way disable this constraint check in Java. Has anyone encountered this and solved this? Any help is highly appreciated.
Best Regards,
Arun
Owner: CN=myapp, OU=mygroup, O=mycompany
Issuer: O=MYCA
Serial number: 4cc8c1da
Valid from: Mon Jan 10 13:46:34 EST 2011 until: Thu Jan 10 14:16:34 EST 2013
Certificate fingerprints:
MD5: 8C:84:7F:7A:40:23:F1:B5:81:CD:F9:0C:27:16:69:5E
SHA1: 9B:39:0B:2F:61:83:52:93:D5:58:E5:43:13:7A:8F:E1:FD:AC:98:A4
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
[1]: ObjectId: 2.5.29.16 Criticality=false
PrivateKeyUsage: [
From: Mon Jan 10 13:46:34 EST 2011, To: Wed Jul 11 21:16:34 EDT 2012]
[2]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_Encipherment
]
[3]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D3 47 35 9B B4 B7 03 18 C6 53 2C B0 FE FD 49 D8 .G5......S,...I.
0010: D0 FB EE 15 ....
]
]
[4]: ObjectId: 1.2.840.113533.7.65.0 Criticality=false
[5]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[CN=CRL413, O=SWIFT]
]]
[6]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
]
****[7]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL server
]****
[8]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 8F AF 56 BC 80 77 A3 FD 9E D2 89 83 98 FE 98 C7 ..V..w..........
0010: 20 65 23 CC e#.
]
]
You could wrap the default trust managers and catch this particular exception. This would be something along these lines:
class IgnoreClientUsageTrustManager extends X509TrustManager {
private final X509TrustManager origTrustManager;
public class IgnoreClientUsageTrustManager(X509TrustManager origTrustManager) {
this.origTrustManager = origTrustManager;
}
public checkClientTrusted(X509Certificate[] chain, String authType
throws IllegalArgumentException, CertificateException {
try {
this.origTrustManager.checkClientTrusted(chain, authType);
} catch (ValidatorException e) {
// Check it's that very exception, otherwise, re-throw.
}
}
// delegate the other methods to the origTrustManager
}
Then, use that trust manager to create an SSLContext and use it with your server.
TrustManagerFactory tmf = TrustManagerFactory.getInstance(
TrustManagerFactory.getDefaultAlgorithm());
tmf.init((KeyStore)null);
TrustManager[] trustManagers = tmf.getTrustManagers();
for (int i = 0; i < trustManagers.length; i++) {
if (trustManagers[i] instanceof X509TrustManager) {
trustManagers[i] = IgnoreClientUsageTrustManager(trustManagers[i]);
}
}
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(... you keymanagers ..., trustManagers, null);
You should initialise your keymanagers from your server keystores (as normal). You should then be able to use the HttpsServer's HttpsConfigurator to set up the SSLContext (see example in the documentation).
This technique isn't ideal, though.
Firstly, ValidatorException is in a sun.* package that's not part of the public API: this code will be specific for the Oracle/OpenJDK JRE.
Secondly, it relies on the fact that the end entity checked (which verifies the key usage extension) happens after the rest of the trust validation (which makes it acceptable to ignore that exception, since you don't ignore other more fundamental checks this way).
You could of course re-implement your own validation instead, using the Java Certificate Path API, and ignoring only the key usage for this purpose. This requires a bit more code.
More generally, you're trying to bypass the specifications anyway, if you want to use a certificate for SSL/TLS as a client certificate when it doesn't have the right extension. The best fix for this is to amend your CA policy, which should be feasible if it's an internal CA anyway. It's quite common for server certificates to have the TLS client extended key usage set too, even with big CAs.