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-----
openssl x509 -inform DER -text
on my DER file gives the dump on the bottom of this question.
I try to read it with:
static PublicKey getCertKey() throws IOException, NoSuchAlgorithmException, InvalidKeySpecException {
URL keyUrl = Resources.getResource(LManager.class, "iid.der");
byte[] keyBytes = Resources.toByteArray(keyUrl);
X509EncodedKeySpec spec = new X509EncodedKeySpec(keyBytes);
KeyFactory kf = KeyFactory.getInstance("RSA");
return kf.generatePublic(spec);
}
And I get:
java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: IOException: ObjectIdentifier() -- data isn't an object ID (tag = -96)
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205)
at java.security.KeyFactory.generatePublic(KeyFactory.java:334)
....
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at Caused by: java.security.InvalidKeyException: IOException: ObjectIdentifier() -- data isn't an object ID (tag = -96)
at sun.security.x509.X509Key.decode(X509Key.java:397)
at sun.security.x509.X509Key.decode(X509Key.java:403)
at sun.security.rsa.RSAPublicKeyImpl.<init>(RSAPublicKeyImpl.java:83)
at sun.security.rsa.RSAKeyFactory.generatePublic(RSAKeyFactory.java:298)
at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:201)
... 25 more
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a9:cb:e1:41:03:30:df:c5
Signature Algorithm: sha1WithRSAEncryption
Issuer: REDACTED
Validity
Not Before: Jun 5 14:28:02 2014 GMT
Not After : Jun 5 14:28:02 2024 GMT
Subject: REDACTED
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:87:bd:18:df:ff:49:12:b6:92:76:e3:c9:21:b4:
86:8d:f2:a9:03:37:7b:64:c3:85:63:bc:0f:67:bc:
f9:76:6a:72:4e:f9:e2:01:52:a3:df:40:6d:3d:91:
99:70:a5:6a:66:c8:ef:1b:18:1d:91:5a:a5:b1:0b:
0b:81:fd:d7:27:22:86:fa:c3:8d:b4:93:d5:98:e4:
2d:08:20:6b:43:44:d6:ae:37:79:2e:bc:65:e4:c3:
71:c4:9c:5d:04:8d:8a:f4:a5:cc:96:52:f0:72:59:
8e:0a:b3:06:55:e3:65:fb:63:b5:d2:4b:5d:e1:38:
87:0b:e8:d2:c0:f8:7f:78:fd
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
25:D6:CC:08:15:CA:B6:F0:9C:59:DC:14:52:2C:EF:B5:41:76:51:38
X509v3 Authority Key Identifier:
keyid:25:D6:CC:08:15:CA:B6:F0:9C:59:DC:14:52:2C:EF:B5:41:76:51:38
DirName:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=ec2.amazonaws.com
serial:A9:CB:E1:41:03:30:DF:C5
X509v3 Basic Constraints:
CA:TRUE
First, openssl -inform DER -text is an error. The openssl program is a wrapper that runs one of a bunch of functions, identified by the first argument, which in this case must be x509, so openssl x509 -inform DER -text.
That's a clue. Your file is an X.509 certificate not (just) a public key. Certificates in general, and X.509 certificates in particular, contain a public key but that is not the same thing as being a public key.
Since your file is an X.509 certificate, use a CertificateFactory of type X.509 to read it. The pattern is similar: use a static .getInstance() method to get a factory then use .generateCertificate() to take some input, here a stream that reads the data (directly from the file, or from memory if you have it buffered), and generate a Certificate object. (Note java.security.cert.Certificate not the obsolete and deprecated java.security.Certificate -- some IDEs may not default to the good one.)
If you want to use the public key in the certificate for something like encrypting or verifying call .getPublicKey() on the Certificate. If you want to look at other information such as the subject name or extensions which are specific to X.509, cast the Certificate to X509Certificate (also in java.lang.security.cert) and use its additional methods.
Also: the certificate is signed with sha1withRSA. The publickey itself is an RSA key, and could be used for any RSA operation -- but since the cert claims this key belongs to a CA, the corresponding privatekey should be used only for signing certs and/or CRLs (controlled by KeyUsage if present, but it's not unless you've redacted it) and thus doing something with this publickey other than verifying those certs and/or CRLs is useless. And since the key is only 1024 bits, using a signing hash stronger than SHA1 would be wasted, except for the facts that RSA-1024 is already considered insecure (since early 2014) and using SHA1-RSA for certificates is considered at risk and prohibited after sometime next year.
We have a process that uses OpenSSL to generate S/MIME digital signatures which need to be verified later using Java 7. On one side we use OpenSSL to read in text files and generate a signed digital output which is verified later.
We used to have the verification using OpenSSL but now we need Java (note: we cannot count on OpenSSL being available now).
We use this to sign: openssl smime -sign -inkey private.key -signer public.key -in ${f} > ${f}.signed and this to verify: openssl smime -verify -noverify -in ${f}.signed
Note: that the verify does not validate the certificates, only checks the signature/contents.
I need to change the verify part of this process to be a java application, preferably with Java 7 (which I think now has the JCE built in).
A sample output is something like ...
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="----185C6C544BB34D30B0835B915C158544"
This is an S/MIME signed message
------185C6C544BB34D30B0835B915C158544
Four score and seven years ago our fathers brought forth on this continent, a
new nation, conceived in Liberty, and dedicated to the proposition that all
men are created equal.
Now we are engaged in a great civil war, testing whether that nation, ...
------185C6C544BB34D30B0835B915C158544
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
MIIKAAYJKoZIhvcNAQcCoIIJ8TCCCe0CAQExDzANBglghkgBZQMEAgEFADALBgkq
hkiG9w0BBwGgggchMIIHHTCCBgWgAwIBAgIEUzuEpzANBgkqhkiG9w0BAQsFADCB
hzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEoMCYGA1UE
CxMfRGVwYXJ0bWVudCBvZiBIb21lbGFuZCBTZWN1cml0eTEiMCAGA1UECxMZQ2Vy
dGlm ...
... JIQeeE=
------185C6C544BB34D30B0835B915C158544--
The signature algorithm is sha256WithRSAEncryption; example ...
openssl smime -pk7out -in message.signed | openssl pkcs7 -text -noout -print_certs
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1396409511 (0x533b84a7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Corp, OU=Acme, OU=CA
Validity
Not Before: May 16 15:27:56 2014 GMT
Not After : May 16 15:57:56 2015 GMT
Subject: C=US, O=Corp, OU=Acme, OU=CBP, CN=foo.acme.corp.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:00:00:00:00:b1:b6:49:6e:ca:d7:61:07:a0:18:
...
c9:de:ab:a7:2f:97:e4:f6:64:37:ec:3a:9d:ae:c0:
16:03
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Certificate Policies:
Policy: 2.16.840.1.101.3.2.1.3.8
...
I have looked at many, many examples, tried multiple ones without success. I wish had had some source to share with you, but the success I have had so far would not be helpful in the least.
This can be done using the Bouncy Castle Crypto APIs where you can use the following official example as reference, https://github.com/bcgit/bc-java/blob/master/mail/src/main/java/org/bouncycastle/mail/smime/examples/ValidateSignedMail.java.
For a simpler example to perform a full validation of a signed email including the certification chain you would do something like this with org.bouncycastle:bcmail-jdk15on:1.52:
import org.bouncycastle.cms.SignerInformation;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.mail.smime.validator.SignedMailValidator;
import javax.mail.internet.MimeMessage;
import java.io.FileInputStream;
import java.security.KeyStore;
import java.security.Security;
import java.security.cert.PKIXParameters;
public class SignedMailValidatorExample {
public static void main(String[] args) throws Exception {
Security.addProvider(new BouncyCastleProvider());
FileInputStream signedEmailInputStream = new FileInputStream("signed_email.eml");
MimeMessage signedEmailMimeMessage = new MimeMessage(null, signedEmailInputStream);
KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream("truststore.jks"), "changeit".toCharArray());
PKIXParameters pkixParameters = new PKIXParameters(trustStore);
pkixParameters.setRevocationEnabled(false);
SignedMailValidator signedMailValidator = new SignedMailValidator(signedEmailMimeMessage, pkixParameters);
boolean successfulValidation = true;
for (SignerInformation signerInformation : signedMailValidator.getSignerInformationStore().getSigners()) {
SignedMailValidator.ValidationResult signerValidationResult = signedMailValidator
.getValidationResult(signerInformation);
if (!signerValidationResult.isValidSignature()) {
successfulValidation = false;
break;
}
}
if (successfulValidation) {
System.out.println("Signed email validated correctly.");
} else {
System.out.println("Signed email validation failed.");
}
}
}
Where truststore.jks should contain a CA certificate (e.g. the issuing CA) that chains to the certificate used to sign the email. Now, you can easily created this file using a software like https://keystore-explorer.org/.
In an attempt to debug this SSL issue that came up on one of our servers recently I wrote a very simple program to connect to an SSL site in our intranet.
URL authURL = null;
BufferedReader br = null;
String url = "https://our.server:443";
try {
authURL = new URL(url);
HttpURLConnection conn = (HttpURLConnection)
authURL.openConnection();
conn.setDoOutput(false);
conn.setDoInput(true);
conn.setAllowUserInteraction(false);
conn.setUseCaches(false);
conn.connect();
} catch (MalformedURLException urlEx) {
urlEx.printStackTrace();
} catch (IOException ex) {
ex.printStackTrace();
} finally {
if (br != null) {
try { br.close(); }
catch (IOException e) {}
}//if
}//finally
This code fails with SSLHandshakeException on one of our servers, but the same exact code works without issue on another server. I ran the programs with SSL debugging enabled and here are results of each server
WORKING SERVER - SLES 11.3, Java IBM 1.6.0 64-bit
... no IV used for this cipher
main, WRITE: SSLv3 Change Cipher Spec, length = 1
JsseJCE: Using cipher RC4 from provider TBD via init
CipherBox: Using cipher RC4 from provider from init IBMJCE version 1.2
JsseJCE: Using MAC SslMacSHA1 from provider TBD via init
MAC: Using MessageDigest SslMacSHA1 from provider IBMJCE version 1.2
*** Finished
verify_data: { 101, 62, 81, 35,
13, 178, 124, 13, 43, 0, 5, 248, 32, 15, 39, 244, 97, 96, 98, 227, 1 8, 172, 226, 53, 71, 218, 210, 21, 72, 85, 44, 130, 175, 194, 228, 34 }
***
main, WRITE: SSLv3 Handshake, length = 60
main, READ: SSLv3 Change Cipher Spec, length = 1
JsseJCE: Using cipher RC4 from provider TBD via init
CipherBox: Using cipher RC4 from provider from init IBMJCE version 1.2
JsseJCE: Using MAC SslMacSHA1 from provider TBD via init
MAC: Using MessageDigest SslMacSHA1 from provider IBMJCE version 1.2
main, READ: SSLv3 Handshake, length = 60
*** Finished
verify_data: { 160, 27, 2, 24, 10, 15, 205, 204, 241, 225, 183, 150, 243, 244, 43, 107, 40, 112, 173 42, 122, 139, 225, 16, 33, 168, 255, 184, 23, 18, 69, 103, 19, 68, 182, 139 }
***
cached session [Session-1, SSL_RSA_WITH_RC4_128_SHA]
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
main, WRITE: SSLv3 Application Data, length = 213
main, READ: SSLv3 Application Data, length = 402
NOT WORKING SERVER: Windows 7, Java JDK 1.6.0_39
... no IV used for this cipher
main, WRITE: SSLv3 Change Cipher Spec, length = 1
*** Finished
verify_data: { 235, 130, 222, 201, 56, 225, 104, 77, 87, 210, 63, 16, 196, 223, 123, 231, 173, 146, 111, 102, 99, 214, 20, 244, 138, 79, 217, 140, 10, 61, 167, 9, 222, 95, 247, 208 }
***
main, WRITE: SSLv3 Handshake, length = 60
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
main, SEND SSLv3 ALERT: fatal, description = handshake_failure
main, WRITE: SSLv3 Alert, length = 22
main, called closeSocket()
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:882)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1203)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1230)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1214)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
at test.Main.main(Main.java:43)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:333)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:863)
... 7 more
Does anyone have any ideas on what I can do to get this simple code working on my Windows 7 machine? I have been at this all day and pretty lost at this point. Thanks for any help!
Update - Requested openssl output
Working server
CONNECTED(00000003)
depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
verify return:1
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 /C=US/O=Thawte, Inc./CN=Thawte SGC CA - G2
verify return:1
depth=0 /C=US/ST=California/L=Riverside/O=University of California-Riverside/OU=Computing and Communication/CN=example.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Riverside/O=University of California-Riverside/OU=Computing and Communication/CN=example.com
i:/C=US/O=Thawte, Inc./CN=Thawte SGC CA - G2
1 s:/C=US/O=Thawte, Inc./CN=Thawte SGC CA - G2
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Not working server
CONNECTED(0000018C)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification
Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Riverside/O=University of California-Riverside/OU=Computing and Communication/CN=example.com
i:/C=US/O=Thawte, Inc./CN=Thawte SGC CA - G2
1 s:/C=US/O=Thawte, Inc./CN=Thawte SGC CA - G2
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
The different results are likely because the the trust store on each machine is slightly different. Here I'm assuming you are running your client locally on the server so each uses the JVM available locally.
But it does not explain the odd looking chain...
0 s:/C=US/ST=California/L=Riverside/O=University of California-Riverside/OU=Computing and Communication/CN=example.com
i:/C=US/O=Thawte, Inc./CN=Thawte SGC CA - G2
1 s:/C=US/O=Thawte, Inc./CN=Thawte SGC CA - G2
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc.
- For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Certificate 0 is the server's certificate, and obviously it must be present.
Certificate 1 is the intermediate required to build the chain. The server must send it too. It must send it to avoid the "which directory" problem. Its a well known problem in PKI, and it means a client does not know which directory to go to for a missing certificate.
I can't find Certificate 1 at Thawte root certificates. Certificate 1's issuer is VeriSign Class 3 Public Primary Certification Authority - G5.
Certificate 2 is VeriSign Class 3 Public Primary Certification Authority - G5. From experience, I know that's a CA, and I'm not sure why it claims to have an issuer.
You can download VeriSign Class 3 Public Primary Certification Authority - G5 from Verisign Root Certifcates. Its filename is VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem. Then:
$ openssl x509 -in VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
18:da:d1:9e:26:7d:e8:bb:4a:21:58:cd:cc:6b:3b:4a
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
Validity
Not Before: Nov 8 00:00:00 2006 GMT
Not After : Jul 16 23:59:59 2036 GMT
Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:af:24:08:08:29:7a:35:9e:60:0c:aa:e7:4b:3b:
...
25:15
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
X509v3 Subject Key Identifier:
7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
Signature Algorithm: sha1WithRSAEncryption
93:24:4a:30:5f:62:cf:d8:1a:98:2f:3d:ea:dc:99:2d:bd:77:
...
a8:ed:63:6a
Notice its a CA: the subject and issuer are the same, there's a bacic constraints with CA:true marked as critical, etc.
So I think you may be using an old Verisign certificate. It might even be expired. But you have access to it, so only you can tell.
Now, here's where it gets really odd: Certificate 3 and Class 3 Public Primary Certification Authority. Its a CA too, but its not certifying anything.
So, I would do the following:
Remove Certificate 2 from the chain
Remove Certificate 3 from the chain
Add VeriSign Class 3 Public Primary Certification Authority - G5 to the trust store
Test both servers with OpenSSL
To test: first, download VeriSign Class 3 Public Primary Certification Authority - G5 from Verisign Root Certifcates. Its filename is VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem.
Second run openssl s_client against each server (command shown below). Include the CAfile option to specify the Verisign trust anchor. Using the required trust anchor, it should finish with: Verify return code: 0 (ok).
$ openssl s_client -connect example.com:443 -CAfile VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem
...
Start Time: 1407273676
Timeout : 300 (sec)
Verify return code: 0 (ok)
openssl s_client will remove Java from the loop, and allow you to verify you have a "known good" baseline for testing further in Java. But I suspect you have an old Verisign Root in the misbehaving server's certificate store, or you are missing a required root in the misbehaving server's certificate store, or both.
I want to encrypt my post payload with an X.509 certificate and the inherited public key. So far I have this java code to perform the encryption
private String encrypt(String str) throws Exception {
ClassPathResource classPathResource = new ClassPathResource("testcert1.crt");
CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
X509Certificate certificate = (X509Certificate)certificateFactory.generateCertificate(classPathResource.getInputStream());
PublicKey pk = certificate.getPublicKey();
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1PADDING");
cipher.init(Cipher.ENCRYPT_MODE, pk);
return Base64.encodeBase64String(cipher.doFinal(str.getBytes()));
}
which returns the base64 encoded string. From the endpoint I am always getting the result, that the certificate is not valid.
So I want to validate my encrypted string on the console using the openssl command, but failing to do so.
I can read out the certificate with: openssl x509 -in testcert1.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=xxx, ST=xxx, L=xxx, O=xxx, OU=xxx, CN=xxx
Validity
Not Before: Jul 24 11:40:39 2013 GMT
Not After : Jul 24 11:40:39 2015 GMT
Subject: C=xxx, ST=xxx, L=xxx, O=xxx, OU=xxx, CN=xxx
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
....
Exponent: 65537 (0x10001)
But I cannot figure out the command lines to encrypt/decrypt a text file using that certificate
You can validate your encrypted string using openssl with the following command:
echo -n 'string to encrypt' | openssl rsautl -encrypt -certin -inkey testcert1.crt | base64
As you are using asymmetric cryptography, if you encrypt using the public key of your certificate, you can only decrypt using the corresponding private key. Make sure you have that key and use it for decryption.