I am creating SSL enabled connection between oracle 11g database (11.2.0.1), and java client using thin client jdbc driver (type 4). We are creating the client/server/root certificates using orapki utility and putting the certificates in oracle wallet.
It seems the default hash algorithm for encryption, when we create certificates using orapki utility (in oracle 11g db) is md5. This was working fine, until we upgraded to jdk1.7 u101. This version of jdk no longer supports MD5. So it seems we need to use SHA-256 as the hash algorithm. I keep getting references that oracle wallet manager 11.2.0.1+ supports SHA-256, but I cannot find any documentation on how to specify SHA-256 as the hash algorithm while creating the certificates.
Is there a way I can generate certificates through orapki/wallet manager with SHA-256 as the hash algorithm?
You can use orapki with -sign_alg sha256 to sign your certificates with sha256 instead of md5.
For example: Creating a self signed certificate used as the trusted authority
orapki wallet create -wallet ./root -pwd welcome123 -nologo
orapki wallet remove -trusted_cert_all -wallet ./root -pwd welcome123 -nologo
orapki wallet add -wallet ./root -dn CN=Certification\ Authority\ For\ Testing,\ O=MyCompany,\ C=US -keysize 2048 -self_signed -validity 7300 -pwd welcome123 -sign_alg sha256 -nologo
orapki wallet export -wallet ./root -dn CN=Certification\ Authority\ For\ Testing,\ O=MyCompany,\ C=US -cert ./root/rootcertificate.crt -pwd welcome123 -nologo
keytool -printcert -file root/rootcertificate.crt
orapki wallet display -wallet ./root -pwd welcome123 -nologo
And the output is:
Owner: CN=Certification Authority For Testing, O=MyCompany, C=US
Issuer: CN=Certification Authority For Testing, O= MyCompany, C=US
Serial number: 0
Valid from: Wed Mar 09 03:35:42 PST 2016 until: Tue Mar 04 03:35:42 PST 2036
Certificate fingerprints:
MD5: D1:EB:E4:27:FB:B1:C9:4A:CB:9D:28:A6:5A:C7:E7:20
SHA1: 39:DD:C2:4A:EA:97:BD:47:52:8C:E6:B9:2C:97:F9:F4:A8:A4:5E:85
SHA256: 04:28:19:01:AC:83:C3:69:D0:C9:1C:6A:94:08:B7:31:0C:65:21:7F:8E:FB:19:50:22:02:C4:9C:69:B1:1E:F6
Signature algorithm name: SHA256withRSA
Version: 1
Related
I am trying to generate specific chain of certificate to use as certs for Corda node.
The certs structure is following
cert_0 -> Subject: Node DN (Legal identity cert)
cert_1 -> Subject: Node DN (Node CA cert)
cert_2 -> Subject: Doorman CA
cert_3 -> Subject: Network Root CA
I have generated all certs and then trying to chain them in two steps:
openssl pkcs12 -export -chain -CAfile nodedoormanrootca.pem -in identity-cert.pem -inkey identity-key.pem -out identity.p12 -name identity-private-key -passout pass:changeit
Step 1 works correctly and as the result I am getting certs bundle consisting of all 4 certs.
Next step is to export it to Java Keystore using keytool.
keytool -v -importkeystore -providerpath bcprov-jdk15on-1.66.jar -provider org.bouncycastle.jce.provider.BouncyCastleProvider -srckeystore identity.p12 -srcstoretype PKCS12 -destkeystore nodekeystore.jks -deststorepass changeit -srcstorepass changeit -alias "identity-private-key"
(I use Bouncy Castle provider because cert_0 uses ed25519 key)
The problem is that after keytool import I have only 1 entry identity-private-key without the rest of the chain.
The cause is that cert_0 and cert_1 have the same subject and keytool thinks that cert_0 is self-signed and thus stops after adding only first cert in the keystore.
So, any idea on how to create such chain of certs in JKS format where two certs will have the same subject (with different public key of course) ?
What comes in mind is to try create some small kotlin program based on Corda sources, but is there any easier solution? Maybe some hack for keytool or smth
There's some important aspects of this to be aware of as currently rolling your own certs isn't supported in certain kinds of corda networks.
if you're doing this on your own machine with a bootstrapped network I'd recommend against it as you can just use the bootstrapper's corda developer certificates.
If you're doing this for production or using your own PKI you should be able to do that with CENM (link here: https://docs.corda.net/docs/cenm/1.3/pki-tool.html)
There are no sample projects that demonstrate creating these certificates. However, if you download the Corda source code and look at X509Utilities.kt(https://github.com/corda/corda/blob/master/node-api/src/main/kotlin/net/corda/nodeapi/internal/crypto/X509Utilities.kt) and CertificatesUtils.kt (https://github.com/corda/corda/blob/master/node/src/main/kotlin/net/corda/node/utilities/CertificatesUtils.kt) you’ll find what is effectively a toolkit for creating certificates.
good luck !
Here is how I understand the flow.
version: '2'
services:
shop_ca:
image: hyperledger/fabric-ca
environment:
- FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
- FABRIC_CA_SERVER_CA_NAME=shop_ca
- FABRIC_CA_SERVER_CA_CERTFILE=/etc/hyperledger/fabric-ca-server-config/ca-cert.pem
- FABRIC_CA_SERVER_CA_KEYFILE=/etc/hyperledger/fabric-ca-server-config/ca-key.pem
ports:
- "7054:7054"
command: sh -c 'fabric-ca-server start -b admin3:admin3'
volumes:
- ./conf.yaml:/etc/hyperledger/fabric-ca-server/fabric-ca-server-config.yaml
container_name: shop_ca
I passed my certfile and keyfile as options.
When the fabric-ca-server starts, what it should do is create ca-cert and ca-key pem files in /etc/hyperledger/fabric-ca-server folder. then use the /etc/hyperledger/fabric-ca-server/fabric-ca-server-config.yaml config file to generate the final certificate(path must be /etc/hyperledger/fabric-ca-server-config/ca-cert.pem) that will be used to issue other certificates.
What I don't understand is this generated certificate /etc/hyperledger/fabric-ca-server-config/ca-cert.pem is self-signed. Question is why? I think what it does is makes csr request to /etc/hyperledger/fabric-ca-server/ca-cert.pem and this ca-cert.pem issues another ca-cert.pem. This question happened on my mind because when I use openssl and print the final generated ca-cert certificate, issuer and subject are both the same. I think issuer has to be /etc/hyperledger/fabric-ca-server/ca-cert.pem and subject must be /etc/hyperledger/fabric-ca-server-config/ca-cert.pem. but both issuer and subject are /etc/hyperledger/fabric-ca-server-config/ca-cert.pem. Why?
The top root certificate for any Certificate Authority is always self-signed (check out the Verisign cert at the bottom of this post) ... that's why you explicitly trust root certificates.
Fabric CA allows you to either specify an existing root key pair or if the specified files do not exist it generates them for you. (if the cert file exists but a matching private key cannot be found you'll get an error and fabric-ca-server will not start).
When fabric-ca-server generates its own self-signed keypair, it actually generates the private key in the msp/keystore folder but it will store the self-signed X509 cert in the file specified via FABRIC_CA_SERVER_CA_CERTFILE if specified else it will use the location in fabric-ca-server-config.yaml. Note that if you use the FABRIC_CA_SERVER_CA_CERTFILE override, the value is not updated in the config file (perhaps this is causing some confusion).
Verisign Primary
Garis-MBP:tmp gsingh$ openssl x509 -noout -text -in verisign.pem
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:
4e:dc:7c:bc:3c:45:1c:bb:2b:e0:fe:29:02:f9:57:
08:a3:64:85:15:27:f5:f1:ad:c8:31:89:5d:22:e8:
2a:aa:a6:42:b3:8f:f8:b9:55:b7:b1:b7:4b:b3:fe:
8f:7e:07:57:ec:ef:43:db:66:62:15:61:cf:60:0d:
a4:d8:de:f8:e0:c3:62:08:3d:54:13:eb:49:ca:59:
54:85:26:e5:2b:8f:1b:9f:eb:f5:a1:91:c2:33:49:
d8:43:63:6a:52:4b:d2:8f:e8:70:51:4d:d1:89:69:
7b:c7:70:f6:b3:dc:12:74:db:7b:5d:4b:56:d3:96:
bf:15:77:a1:b0:f4:a2:25:f2:af:1c:92:67:18:e5:
f4:06:04:ef:90:b9:e4:00:e4:dd:3a:b5:19:ff:02:
ba:f4:3c:ee:e0:8b:eb:37:8b:ec:f4:d7:ac:f2:f6:
f0:3d:af:dd:75:91:33:19:1d:1c:40:cb:74:24:19:
21:93:d9:14:fe:ac:2a:52:c7:8f:d5:04:49:e4:8d:
63:47:88:3c:69:83:cb:fe:47:bd:2b:7e:4f:c5:95:
ae:0e:9d:d4:d1:43:c0:67:73:e3:14:08:7e:e5:3f:
9f:73:b8:33:0a:cf:5d:3f:34:87:96:8a:ee:53:e8:
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:
f6:a5:79:22:38:ec:c4:a7:a0:78:12:ad:62:0e:45:70:64:c5:
e7:97:66:2d:98:09:7e:5f:af:d6:cc:28:65:f2:01:aa:08:1a:
47:de:f9:f9:7c:92:5a:08:69:20:0d:d9:3e:6d:6e:3c:0d:6e:
d8:e6:06:91:40:18:b9:f8:c1:ed:df:db:41:aa:e0:96:20:c9:
cd:64:15:38:81:c9:94:ee:a2:84:29:0b:13:6f:8e:db:0c:dd:
25:02:db:a4:8b:19:44:d2:41:7a:05:69:4a:58:4f:60:ca:7e:
82:6a:0b:02:aa:25:17:39:b5:db:7f:e7:84:65:2a:95:8a:bd:
86:de:5e:81:16:83:2d:10:cc:de:fd:a8:82:2a:6d:28:1f:0d:
0b:c4:e5:e7:1a:26:19:e1:f4:11:6f:10:b5:95:fc:e7:42:05:
32:db:ce:9d:51:5e:28:b6:9e:85:d3:5b:ef:a5:7d:45:40:72:
8e:b7:0e:6b:0e:06:fb:33:35:48:71:b8:9d:27:8b:c4:65:5f:
0d:86:76:9c:44:7a:f6:95:5c:f6:5d:32:08:33:a4:54:b6:18:
3f:68:5c:f2:42:4a:85:38:54:83:5f:d1:e8:2c:f2:ac:11:d6:
a8:ed:63:6a
For mostly learning purposes so far, I'm attempting to generate a SHA2 Certificate using Java's keytool. However, when I generate the keys, it says that Certificate Fingerprint is SHA1, not SHA2.
keytool -genkey -alias test_sha2_rsa_key -keyalg RSA -keysize 2048 -keystore .keystore -sigalg "SHA256withRSA"
Here is the result when I list the keys.
keytool -list
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
test_sha2_rsa_key, Jul 6, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): DD:9E:55:B7:90:9F:91:6C:68:D3:5C:24:E7:D4:45:D1:7D:8C:3A:5A
Am I reading this wrong, or doing this wrong?
The SHA-1 fingerprint is calculated over the binary (DER) encoded certificate. It is not contained in the certificate and is - as Dave already stipulated - not related with the signature over the tbsCertificate (the part of the certificate "to be signed"). Actually, as it is over the entire certificate, the signature algorithm reference (OID) and signature itself is also included in the fingerprint data.
Beware that fingerprinting a certificate using SHA-1 is about as safe as signing a certificate with SHA-1. It depends on how the fingerprint is used, but in principle this could introduce a vulnerability if (or when) SHA-1 is broken.
I have created a Self-Signed Certificate in Mac OS using Keychain Access to be used as a certificate for my AIR Application. After exporting a release build for my app in Flash Builder 4.6, I have verified my apk using jarsigner by executing the following command:
jarsigner -verify -verbose -certs myapp.apk
then, the following message was returned:
jar verified.
Warning:
This jar contains entries whose signer certificate is not yet valid.
is it ok to publish this app on Google Play?
if possible, how to validate my self-signed certificate?
root cause for my problem: since Google Play requires a certificate to be expired after October 22, 2033, i have changed my system date to an advance date.
Valid value for the validity period of Keychain Access certificate assistant is 20 years so if I'll create a new certificate, it will expire on June 26, 2033 which fails to achieve the requirement.
A validity period for an X509 certificate is the number of days the certificate
is valid from the time it is issued. Certificates issued by Certificate Assistant
have a maximum validity period of 20 years.
upon using this certificate for the code signing of my air application, Google Play prompts an error upon uploading the apk
Upload failed
You uploaded an APK signed with a certificate that is not yet valid.
You need to sign your APK with a certificate that is currently valid.
Learn more about signing.
So i created a new certificate using keytool by executing the following commands:
$ keytool -keystore cert.jks -genkeypair -alias cert -keyalg RSA -keysize 2048 \
-validity 18250 -dname 'CN=cert,OU=org,O=org,L=location,ST=state,C=PH'
$ keytool -keystore cert.jks -exportcert -alias cert \
| openssl x509 -inform der -text
$ keytool -importkeystore -srckeystore cert.jks -destkeystore cert.p12 \
-srcstoretype jks -deststoretype pkcs12
When using OpenSSL utils for signing .csr request, its possible to use "openssl ca" util and "openssl x509" util.
Openssl ca's text config file has all needed x509 options like keyUsage, extendedKeyUsage.
Openssl x509's command line has options -addtrust and -addreject. When you sign a certificate with those options, you can see them later in "openssl x509 -text" output, something like:
user#inet-pc:~$ openssl x509 -req -in test.csr -CA ca.crt -CAkey ca.key -set_serial 1 -out test.crt -setalias "zzzz test alias" -addtrust emailProtection -addreject serverAuth
^ signing test.csr using own CA key and cert
user#inet-pc:~$ openssl x509 -text -in test.crt -nooutCertificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=RU, ST=Some-State, O=Internet Widgits Pty Ltd, OU=sdds, CN=ca
Validity
Not Before: Apr 23 06:24:58 2013 GMT
Not After : May 23 06:24:58 2013 GMT
Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=test
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
(huge text here)
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
(huge text here)
Trusted Uses:
E-mail Protection
Rejected Uses:
TLS Web Server Authentication
Alias: zzzz test alias
^ Trusted and Rejected uses. What are those uses for and how do they work? Why I cannot find any mention of them in X509 RFC5280? How to use "openssl ca" to add same trusted/rejected uses? What about "clientAuth" usage? It isnt listed in "trusted" or "rejected" - will this certificate be trusted by most common applications?
Update 1: OpenSSL's x509 manual says that "trust" settings are valid for OpenSSL's "verify" util, but what is that util for? Can invalid "trust" settings cause verification fail by usual http browsers/etc?
You need to look at the section 4.2.1.12 "Extended Key Usage" of the rfc5280 :
https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12
Edit:
You are right, I am afraid I read your question too quickly. The trust settings are an OpenSSL auxiliary information, which as far as I know is stil experimental. See :
https://www.openssl.org/docs/apps/x509.html#TRUST_SETTINGS
Again, I am sorry for my previous answer.