We Keep Coding

Client certificate missing: How to recover it

I am on a team that is are trying to connect a Java J2SE application to a secure corporate web services site using certificates. None of the team members have prior experience creating certificates and coding for this type of connection.
We prepared and submitted a CSR and received a .p7b certificate from the web service site. The .p7b contains two certificates: one for us issued by the web services site and a second for the web services site issued by the corporate owner’s own CA. Both appear in the keystore list below. The keystore is referenced in a custom SSLContext and the Java code creates an Apache HttpClient with that SSLContext without error.
When the Java code attempts to execute an HttpGet, the web service site rejects the SSLHandshake and terminates the connection with the error:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
In the handshake debug trace, in step 13 of the handshake, is the message:
ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
Certificate chain
Empty
Keytool lists the contensts of the keystore as:
(corporate identities redacted)
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: server
Creation date: Mar 28, 2019
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: ...
Issuer: ...
Serial number: ...
Valid from: Mon Mar 11 19:00:00 CDT 2019 until: Wed Mar 11 18:59:59 CDT 2020
Certificate fingerprints:
SHA1: ...
SHA256: ...
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.16.840.1.113733.1.6.9 Criticality=false
0000: 01 01 FF ...
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://onsite-crl.pki.digicert.com/ATTServicesIncApplicationCertificates/LatestCRL.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_Encipherment
]
#5: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL client
]
Certificate[2]:
Owner: ...
Issuer: ...
Serial number: ...
Valid from: Wed Feb 23 18:00:00 CST 2011 until: Tue Feb 23 17:59:59 CST 2021
Certificate fingerprints:
SHA1: ...
SHA256: ...
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 97 20 99 C2 73 2A 45 EB E0 02 7F 47 DA 7B AB 7C . ..s*E....G....
0010: EB 1F AF 6E ...n
]
]
#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:0
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://onsitecrl.verisign.com/offlineca/ATTServicesIncATTServicesIncRootCA.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]
#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
CN=VeriSignMPKI-2-51
]
#6: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 25 64 37 69 DB DC 57 99 43 80 79 29 90 6C B8 13 %d7i..W.C.y).l..
0010: 58 EE B6 D0 X...
]
]
*******************************************
*******************************************
]
}
It appears that the keystore includes an entry for our private key but not a client certificate; only the two certificates from the .p7b from the web services site are listed.
The StackOverflow post at:
why doesn't java send the client certificate during SSL handshake?
suggests exporting the client certificate from the keystore and editing the certificate chain. This does not relieve the problem, apparently because the keystore contains our private key but not our signed certificate.
I do not have an artifact that identifies as the client certificate. The Oracle procedure given at:
https://docs.oracle.com/cd/E19509-01/820-3503/ggezu/index.html
suggests the signed client certificate should have been created in the process of preparing the original CSR (step 3 of the procedure) , however we do not appear to have that certificate file as a separate artifact.
I think we need to reconstruct the client certificate and import it into the proper location of the certificate chain in the keystore. Since we do not appear to have the original file created when the CSR was created, can the client certificate be re-created now from scratch (step 3 - 5 of the Oracle procedure) and edited back into the chain? Is there a way to extract or reconstitute the client certificate from the original CSR?
Any questions, insights or suggestions very much appreciated. Thanks.

It appears that the keystore includes an entry for our private key but not a client certificate; only the two certificates from the .p7b from the web services site are listed.
The PrivateKeyEntry you show listed by keytool does contain a client certificate (by BC, KU and NCT), and a CA certificate that presumably is the issuing (parent) cert for that client cert. (If you imported these certs to this keystore with keytool, the CA cert is definitely the issuer because keytool verifies that; if you used another tool it should enforce the same requirement, but might not.) You describe the p7b as containing "second for the web services site issued by the corporate owner’s own CA" but (1) if that were the case keytool would not have imported it as part of the same chain and (2) it would make no sense, because the client does not need a CA-issued (i.e. not self-signed) server cert in its keystore or truststore, only the cert of the server's CA in its truststore, and that as a separate entry not in the client's PrivateKeyEntry even if it's a shared file.
Per your description you are getting a javax.net.debug=ssl trace, so look at the part of that trace where it loads the keystore and make sure this entry is getting loaded, and look at the server's *** CertificateRequest under Cert Authorities to see what CA(s) it is asking for (immediately before *** ServerHelloDone) and compare that(those) to the actual CA for the chain in your keystore (unredacted). Since you are using Apache HttpClient, if you are using one of the overloads that specifies a PrivateKeyStrategy make sure it selects the alias correctly.

java.security.cert.CertPathValidatorException: Certificate chaining error

I have the following application error when accessing https://..appRoot../TestJavaMongo/test/mongo/all by following the doc: https://medium.com/#blumareks/mongodb-for-you-a-hardcore-java-cloud-developer-f67b909834f4
I'm testing to connect the Mongo DB service from the Liberty Java CF app on IBM Cloud. How to resolve the error?
``` Error 500: com.mongodb.MongoTimeoutException: Timed out after
30000 ms while waiting for a server that matches
WritableServerSelector. Client view of cluster state is {type=UNKNOWN,
servers=[{address=sl-us-south-1-portal.16.dblayer.com:50233,
type=UNKNOWN, state=CONNECTING,
exception={com.mongodb.MongoSocketWriteException: Exception sending
message},
caused by {javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h:
PKIX path building failed:
java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl
could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued
by CN=********* is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining
error}, ...
$ keytool -list -v -keystore mongoKeyStore
Enter keystore password:
Keystore type: JKS Keystore provider: SUN
Your keystore contains 1 entry
Alias name: mykey Creation date: 24/06/2017 Entry type:
trustedCertEntry
Owner: CN=mwsadows#us.ibm.com-0b24b0ff06b390e0cc5e803aecd5ec82 Issuer:
CN=mwsadows#us.ibm.com-0b24b0ff06b390e0cc5e803aecd5ec82 Serial number:
59491e1b Valid from: Tue Jun 20 23:07:39 AEST 2017 until: Sat Jun 20
23:00:00 AEST 2037 Certificate fingerprints: MD5:
A4:54:21:6A:52:E1:8B:CB:07:CC:25:A3:3B:1A:8B:05 SHA1:
BE:5D:AE:94:C3:A5:37:2D:43:B2:E7:FC:CF:39:19:EE:B8:10:29:9B SHA256:
D5:6B:EB:D6:88:36:D4:77:06:9B:8D:2B:83:39:9B:95:A5:E3:22:09:99:EF:32:89:31:E2:88:C2:86:58:83:62
Signature algorithm name: SHA512withRSA Version: 3
Extensions:
1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 65 2C 47 37 D6 4C B7 24 E9 A1 AA 14 01 4A 12
AD e,G7.L.$.....J.. 0010: 63 E0 7C 56
c..V ] ]
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: 65 2C 47 37 D6 4C B7 24 E9 A1 AA 14 01 4A 12
AD e,G7.L.$.....J.. 0010: 63 E0 7C 56
c..V ] ]

I recently had this same issue with our db provider, they sent me their .crt file and I had to create a keystore with it.
keytool -import -alias "name" -file "/path/to/file" -keystore "/path/to/keystore/file" -storetype pkcs12 -storepass "keystorepass"
then at my main class I defined truststore and truststore pass:
System.setProperty("javax.net.ssl.trustStore", "/path/to/keystore/file");
System.setProperty("javax.net.ssl.trustStorePassword", "keystorepass");
Hope it helps.

As the error says, the certificate isn't trusted. I see that tutorial has a pretty substantial section on importing the certificate from the Mongo service into a keystore and setting it as the trustStore for Liberty. Double check those steps to make sure that you:
Correctly obtained and saved the certificate from the Mongo service, ie that it is not incomplete or corrupted or anything.
Check that you created a keystore using the keytool command in the correct location, and that you replaced the one from the repository if you checked that out, and that it includes the certificate you saved for the Mongo server. You can use keytool -list -v -keystore <path_to_keystore.jks> on your keystore to see what's inside.
Check that you configured Liberty correctly to use this keystore as your trust store. I think the tutorial is a little misleading, as it says
A typical application will also need to set several JVM system
properties to ensure that the client presents an TLS/SSL certificate
to the MongoDB server: javax.net.ssl.keyStore The path to a key store
containing the client’s TLS/SSL certificates
javax.net.ssl.keyStorePassword The password to access this key store
However, I think you actually need to set this keystore you created as the value for the javax.net.ssl.trustStore property (and set the trustStorePassword property accordingly) because the JVM uses the trustStore to check the public keys of hosts it is connecting to for trust.
Either way, make sure those properties are set appropriately and that Liberty is not throwing up any errors in the logs related to it on server start.
Once you have verified the whole chain (that you have exported the correct certificate, that you have created a keystore that contains that certificate, and that you have set that keystore as the truststore for the server,) you should have security set up to talk to the Mongo server correctly. If you have changed the existing truststore while the server is running you have to restart the server for it to pick up those changes.

Oracle Java 7 keytool cannot import pkcs11 keystore into JKS: not PKCS 8 encoded

I have followed the Oracle guide to try to import my PKCS#11 keystore in my smartcard into a JKS keystore in my filesystem, in Ubuntu 16.04. I have Oracle JDK 7 installed, and the driver file of my Izenpe card.
http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html
And I have encountered this bug with Open JDK 7:
java keytool with opensc pkcs#11 provider only works with debug option enabled
stating that with Open JDK the implementation has a bug and you should get around it. The post doesn't solve my problem and I switch to Oracle JDK 7 and I can list the private key entry in my card:
keytool -keystore NONE -storetype PKCS11 \
-providerClass sun.security.pkcs11.SunPKCS11 \
-providerArg $JAVA_HOME/config.ini \
-v -list
where the config.ini is:
name=Izenpe-static
library=/usr/lib/libbit4ipki.so
showInfo=true
So, I get:
easternfox#easternfox-Ubuntu:~/下载/electronic-wechat-production$ keytool -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /home/easternfox/文档/config.ini -v -list
Information for provider SunPKCS11-Izenpe-static
Library info:
cryptokiVersion: 2.20
manufacturerID: bit4id srl
flags: 0
libraryDescription: bit4id PKCS#11
libraryVersion: 1.02
All slots: 0
Slots with tokens: 0
Slot info for slot 0:
slotDescription: Cherry GmbH SmartBoard XX44 [Smart Card Reader USB] 00 00
manufacturerID: unknown
flags: CKF_TOKEN_PRESENT | CKF_REMOVABLE_DEVICE | CKF_HW_SLOT
hardwareVersion: 0.00
firmwareVersion: 0.00
Token info for token in slot 0:
label: IZENPE
manufacturerID: Oberthur Technologies
model: Cosmo ID ONE (L)
serialNumber: 1550001000002654
flags: CKF_RNG | CKF_LOGIN_REQUIRED | CKF_USER_PIN_INITIALIZED | CKF_TOKEN_INITIALIZED
ulMaxSessionCount: CK_EFFECTIVELY_INFINITE
ulSessionCount: 0
ulMaxRwSessionCount: CK_EFFECTIVELY_INFINITE
ulRwSessionCount: CK_UNAVAILABLE_INFORMATION
......
Enter keystore password:
Keystore type: PKCS11
Keystore provider: SunPKCS11-Izenpe-static
Your keystore contains 1 entry
Alias name: CIUDADANO FICTICIO ACTIVO
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: SERIALNUMBER=92920000T, SURNAME=FICTICIO, GIVENNAME=CIUDADANO, CN=CIUDADANO FICTICIO ACTIVO, DNQ=-dni 92920000T, OU=Condiciones de uso en www.izenpe.com nola erabili jakiteko, OU=Herritar ziurtagiria - Certificado de ciudadano, OU=Ziurtagiri onartua - Certificado reconocido, C=ES
Issuer: CN=Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (4), OU=NZZ Ziurtagiri publikoa - Certificado publico SCI, O=IZENPE S.A., C=ES
......
#10: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 00 DE A8 79 08 14 F9 FA 05 2C BF 8B 65 99 69 91 ...y.....,..e.i.
0010: EA 5D 70 45 .]pE
]
]
*******************************************
*******************************************
And, when I try keytool -importkeystore, I have several errors:
Running keytool -importkeystore --help gives me a lot of useful information:
keytool -importkeystore [OPTION]...
Imports one or all entries from another keystore
Options:
-srckeystore <srckeystore> source keystore name
-destkeystore <destkeystore> destination keystore name
-srcstoretype <srcstoretype> source keystore type
-deststoretype <deststoretype> destination keystore type
-srcstorepass <arg> source keystore password
-deststorepass <arg> destination keystore password
-srcprotected source keystore password protected
-srcprovidername <srcprovidername> source keystore provider name
-destprovidername <destprovidername> destination keystore provider name
-srcalias <srcalias> source alias
-destalias <destalias> destination alias
-srckeypass <arg> source key password
-destkeypass <arg> destination key password
-noprompt do not prompt
-providerclass <providerclass> provider class name
-providerarg <arg> provider argument
-providerpath <pathlist> provider classpath
-v verbose output
Use "keytool -help" for all available commands
If I omit srckeypass/destkeypass, I have:
easternfox#easternfox-Ubuntu:$ keytool -srckeystore NONE -srcstoretype PKCS11 \
-destkeystore /home/easternfox/my.new.jks -deststoretype jks -deststorepass qwerqwer \
-providerClass sun.security.pkcs11.SunPKCS11 \
-providerArg $JAVA_HOME/config.ini
-v -importkeystore
Information for provider SunPKCS11-Izenpe-static
Library info:
cryptokiVersion: 2.20
manufacturerID: bit4id srl
flags: 0
libraryDescription: bit4id PKCS#11
libraryVersion: 1.02
All slots: 0
Slots with tokens: 0
Slot info for slot 0:
slotDescription: Cherry GmbH SmartBoard XX44 [Smart Card Reader USB] 00 00
manufacturerID: unknown
flags: CKF_TOKEN_PRESENT | CKF_REMOVABLE_DEVICE | CKF_HW_SLOT
hardwareVersion: 0.00
firmwareVersion: 0.00
Token info for token in slot 0:
label: IZENPE
manufacturerID: Oberthur Technologies
model: Cosmo ID ONE (L)
serialNumber: 1550001000002654
flags: CKF_RNG | CKF_LOGIN_REQUIRED | CKF_USER_PIN_INITIALIZED | CKF_TOKEN_INITIALIZED
ulMaxSessionCount: CK_EFFECTIVELY_INFINITE
ulSessionCount: 0
ulMaxRwSessionCount: CK_EFFECTIVELY_INFINITE
ulRwSessionCount: CK_UNAVAILABLE_INFORMATION
ulMaxPinLen: 8
ulMinPinLen: 4
ulTotalPublicMemory: 65535
....
Enter source keystore password:
Problem importing entry for alias CIUDADANO FICTICIO ACTIVO: java.security.KeyStoreException: non-null password required to create PrivateKeyEntry.
Entry for alias CIUDADANO FICTICIO ACTIVO not imported.
Do you want to quit the import process? [no]: n
Import command completed: 0 entries successfully imported, 1 entries failed or cancelled
[Storing /home/easternfox/my.new.jks]
So, I see the non-null password required error, and I try to specify the srckeypass and destkeypass, and get another error:
keytool error: java.lang.Exception: if alias not specified, destalias, srckeypass, and destkeypass must not be specified
java.lang.Exception: if alias not specified, destalias, srckeypass, and destkeypass must not be specified
at sun.security.tools.KeyTool.doImportKeyStore(KeyTool.java:1864)
at sun.security.tools.KeyTool.doCommands(KeyTool.java:1024)
at sun.security.tools.KeyTool.run(KeyTool.java:340)
at sun.security.tools.KeyTool.main(KeyTool.java:333)
So, I must add srcalias. So I do it, and:
Problem importing entry for alias CIUDADANO FICTICIO ACTIVO: java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded.
Entry for alias CIUDADANO FICTICIO ACTIVO not imported.
[Storing /home/easternfox/my.new.jks]
Another error has occurred, suggesting that the private key in the card is not PKCS#8 encoded.
How to solve this? Is this a bug? Or just manufacturer-related issue?
What I have tried:
I tried to specifying the argument -providerpath to change to another sunpkcs11.jar, of Oracle JDK 8, to no avail.
I changed the driver coming with the card to another version. Not working.
EDIT：
I have tried to code a little and get the same error, with some stacktraces:
java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded
at sun.security.provider.KeyProtector.protect(KeyProtector.java:174)
at sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:259)
at sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:55)
at java.security.KeyStore.setKeyEntry(KeyStore.java:909)
at com.JSILTRA.logic.PKCS11KeyStoreConstuctor.constructJKSKeyStore(PKCS11KeyStoreConstuctor.java:66)
at com.JSILTRA.logic.PKCS11KeyStoreConstuctor.main(PKCS11KeyStoreConstuctor.java:22)

Invalid certification path - tomcat, SSL, Jasig

I try to login into cas-management-app using cas-server-webapp and I have problems with certification path.
I generated keystore file:
"$JAVA_HOME/bin/keytool.exe" -genkey -alias tomcat -keyalg RSA
Enter keystore password: pass
Re-enter new password: pass
What is your first and last name?
[Unknown]: localhost
What is the name of your organizational unit?
[Unknown]: localhost
What is the name of your organization?
[Unknown]: localhost
What is the name of your City or Locality?
[Unknown]: Crc
What is the name of your State or Province?
[Unknown]: Lesser
What is the two-letter country code for this unit?
[Unknown]: PL
Is CN=localhost, OU=localhost, O=localhost, L=Crc, ST=Lesser, C=PL correct?
[no]: yes
Enter key password for <tomcat>
(RETURN if same as keystore password): pass
Re-enter new password: pass
I changed Tomcat configuration:
server.xml
<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="C:/Users/Mateusz/.keystore" keystorePass="pass"
clientAuth="false" sslProtocol="TLS"/>
Value of keystoreFile is valid path.
In next step I exported (using browser) certificate to localhost.crt and added it to cacerts:
"$JAVA_HOME/bin/keytool.exe" -import -alias incommon -file <localhost.crt location> -keystore cacerts -storepass changeit
When I list cacerts everything is OK:
$ "$JAVA_HOME/bin/keytool.exe" -v -list -keystore cacerts -storepass changeit
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: incommon
Creation date: 2015-11-02
Entry type: trustedCertEntry
Owner: CN=localhost, OU=localhost, O=localhost, L=Crc, ST=Lesser, C=PL
Issuer: CN=localhost, OU=localhost, O=localhost, L=Crc, ST=Lesser, C=PL
Serial number: 32432ba5
Valid from: Mon Nov 02 19:19:02 CET 2015 until: Sun Jan 31 19:19:02 CET 2016
Certificate fingerprints:
MD5: 9F:A6:4A:B0:F3:26:89:60:73:5C:CA:36:59:0A:32:F9
SHA1: 62:12:60:61:A9:3D:83:E8:1B:C5:3A:85:27:9A:7F:A7:D3:54:7D:D1
SHA256: F1:43:EE:6E:F7:D4:C6:DF:20:16:71:C1:0D:F5:88:5F:85:21:BE:E6:3C:E5:C1:8D:28:6A:51:BB:38:E7:A2:94
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B0 94 2A 98 B8 A4 21 71 EB 34 46 D4 16 67 24 E8 ..*...!q.4F..g$.
0010: 67 61 C4 D6 ga..
]
]
When I run Tomcat server, open https://localhost:8443/cas-management I can see login form. After writing user login and password I see message:
The CAS management webapp is unavailable.
There was an error trying to complete your request. Please notify your support desk or try again.
Log files give me information
SEVERE: Servlet.service() for servlet [default] in context with path [/cas-management] threw exception
java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I tried to install certs using InstallCert class but nothing changed. I also tried setup path to trust store (jssecacerts) using truststoreFile and truststorePass in Tomcat configuration.
I have no idea what next I can do to successfully configure SSL on my Tomcat server.

keytool Java and TLS/SSL

I have a socket client and server socket. The server has a keystore with a key in it.
keytool -genkey -alias mystuff -keyalg RSA -keystore keystore.jks -keysize 2048
This page says that it generates a key pair when the above command is run. https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html
When I run this command:
keytool -list -v -keystore keystore.jks
I can see:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: mystuff
Creation date: 25-Jun-2015
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Richard, OU=OSS, O=OSS, L=Yat, ST=Hamp, C=GB
Issuer: CN=Richard, OU=OSS, O=OSS, L=Yat, ST=Hamp, C=GB
Serial number: 48ee5103
Valid from: Thu Jun 25 17:09:18 BST 2015 until: Sun Jun 19 17:09:18 BST 2016
Certificate fingerprints:
MD5: 60:63:F2:41:A3:AB:DB:E0:63:F9:B0:E4:C8:2C:90:D4
SHA1: 52:8A:F7:76:82:B7:E9:BE:D3:4E:4A:3C:DD:CF:8A:58:A6:9F:70:DE
SHA256: 3C:80:C1:0E:E7:30:DD:69:9F:97:A9:02:F9:4E:6E:57:84:82:C5:22:0E:7F:7A:EE:C1:D2:7A:8A:45:A3:86:79
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 42 4F 07 15 3A 9A 8C 59 6A 65 EB B6 62 FD 77 C5 BO..:..Yje..b.w.
0010: AC E3 B2 4F ...O
]
]
What I am seeing there is the certificate but what does the entrytype: PrivateKeyEntry mean ?
So ... when I load the Java Server:
java -Djavax.net.ssl.keyStore=keystore.jks -Djavax.net.ssl.keyStorePassword=somepassword EchoServer
I can point it to the keystore so it can be used in setting up the SSLServerSocket.
Now on the client side does the client just need the exported crt from that key store using this command ?
keytool -export -alias mystuff -file mystuff.crt -keystore keystore.jks
Or is something else required to enable secure SSL between the Java Sockets.
Additional Information
Standard Java Notes
Running server and client using SSL
http://stilius.net/java/java_ssl.php
First copy certificate file that you created before into working directory and run server with these parameters (notice that you have to change keyStore name and/or trustStrorePassword if you specified different options creating certificate:
java -Djavax.net.ssl.keyStore=mySrvKeystore -Djavax.net.ssl.keyStorePassword=123456 EchoServer
And now again copy certificate file that you created before into working directory and run client with these parameters (notice that you have to change keyStore name and/or trustStrorePassword if you specified different options creating certificate:
java -Djavax.net.ssl.trustStore=mySrvKeystore -Djavax.net.ssl.trustStorePassword=123456 EchoClient
If you want SSL debug information just add these parameters when running server and/or client:
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -Djavax.net.debug=ssl
javax.net.ssl.keyStore- Location of the Java keystore file containing an application process's own certificate and private key. On Windows, the specified pathname must use forward slashes, /, in place of backslashes.
javax.net.ssl.keyStorePassword - Password to access the private key from the keystore file specified by javax.net.ssl.keyStore. This password is used twice: To unlock the keystore file (store password), and To decrypt the private key stored in the keystore (key password).
javax.net.ssl.trustStore - Location of the Java keystore file containing the collection of CA certificates trusted by this application process (trust store). On Windows, the specified pathname must use forward slashes, /, in place of backslashes, .
If a trust store location is not specified using this property, the SunJSSE implementation searches for and uses a keystore file in the following locations (in order):
$JAVA_HOME/lib/security/jssecacerts
$JAVA_HOME/lib/security/cacerts
javax.net.ssl.trustStorePassword - Password to unlock the keystore file (store password) specified by javax.net.ssl.trustStore.
javax.net.ssl.trustStoreType - (Optional) For Java keystore file format, this property has the value jks (or JKS). You do not normally specify this property, because its default value is already jks.
javax.net.debug - To switch on logging for the SSL/TLS layer, set this property to ssl.
Richard