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.
Related
We have a process to request a signed cert from a CA and we get back 3 files:
cert.cer, cert.key, and cert.p12
I now need to build a valid/usable cert store from those files. I have copies of the CA & intermediate certs locally on my server. So I'm trying to import everything by using keytool. But I end up with a store full of about 100 certs plus the cert for my server. But when I try to use them I'm getting an error that the server cert is not valid unless the signing certs are also in the store. Basically there's no chain even though I the server cert says it was issued by the intermediate cert in the store. I use the following commands to import my certs and ca trusts.
keytool -v -importkeystore -srckeystore "cacerts.p12" -srcstorepass "$CA_PASS" -srcstoretype "pkcs12" -destkeystore "$KEYSTORE_NAME" -deststorepass "$STORE_PW" -deststoretype "jks";
keytool -importkeystore -v -srckeystore "$CERT_NAME.p12" -srcstorepass "$STORE_PW" -srcstoretype "pkcs12" -destkeystore "$KEYSTORE_NAME" -deststorepass "$STORE_PW" -deststoretype "jks";
I'm not sure what step I'm missing. This is an Ubuntu 20.04 server.
How do I create a usable certificate-store ..
Usable is the keyword here - what are you trying to use the keystore for? (usually - SSL, client authentication or WS-Security)
getting an error that the server cert is not valid unless the signing certs are also in the store
There are different files for different purpose:
cert.cer - a public key with a CA-signed certificate
cert.key - a private key
cert.p12 - a keystore, may contain the private key, may contain the public key with its certificate, usually contains both (private key, public key, certificate). So - better validate what does the p12 keystore really contain.
The PKCS#12 keystore usually can be used as it is, often no need to import into a separate JKS. However - depends on the software.
BTW - maybe you could get a keystore-explorer, an opensource gem software giving you a great overview when not understanding the details or cli options.
Basically there's no chain even though I the server cert says it was issued by the intermediate cert in the store
Depends on the usage, but the best practice is having the CA root or its intermediate certificates imported in the truststore.
To import a CA reply in the keytool, you simply import a CA reply (issued certificate) with the same alias name as its private key. I'm not sure if you can create a whole certificate chain this way, you may have a look at the mentioned keystore-explorer to be sure.
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 !
I just got an Thawte 123 SSL Certificate and have problems uploading it to AWS to use it with CloudFront as Custom SNI SSL Certificate. AWS refuses the CA Chain. I'm using the Thawte Intermediate CA bundle for SSL Web Server and Thawte Wildcard certificates.
To be able to use my private key I converted it to an RSA key with:
openssl rsa -in private.key -out private-rsa-key.pem`
And tried to upload it with:
aws iam upload-server-certificate --server-certificate-name example.com-certificate --certificate-body file://certificate.pem --private-key file://private.pem --certificate-chain https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL_CA_Bundle.pem --path /cloudfront/example.com/
Resulting in the following error:
A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 0
Even Inserting the thawte_Primary_Root_CA.pem into the certificate chain as first immediate signing certificate, doesn't resolve the problem.
A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 1
Is the Thawte CA Chain not compatible to AWS?
I am having the same issue right now, and tried everything.
Using SSL123 certificate (My rsa key and pem are ok)
I can't get to work the primary and secondary certs provided by Thawte, in any order.
I tried primary alone, secondary alone, primary+secondary, secondary+primary, also tried with the root cert and also tried with the primary&secondary from:
https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL123_SecondaryCA.pem
https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL123_PrimaryCA.pem
The only thing I can get from ELB is:
Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 0
Where the index is not always -1, but also 0,1 and 2 depending on the order and the number of certs included.
[SOLVED FOR ME]
Apparently, the EC2 instance from which you create the certificate affects. I used a standard EBS instance with default AMI, and transformed the certificate provided by Thwate again, and it did work.
Here the steps:
CSR:
keytool -genkey -keysize 2048 -keyalg RSA -alias mycertificate -keystore keystore.jks
Once Thatwe responds: (Primary is the second certificate in the chain of the email).
Import the three certificates in the keystore.jks
keytool -import -alias Primary -trustcacerts -file Primary.crt -keystore keystore.jks
keytool -import -alias Secondary -trustcacerts -file Secondary.crt -keystore keystore.jks
keytool -import -alias mycertificate -trustcacerts -file mycertificate.cer -keystore keystore.jks
JSK > P12 - Transform keystore.jks into p12 format
keytool -importkeystore -srckeystore keystore.jsk -destkeystore keystore.p12 -srcstoretype jks -deststoretype pkcs12
P12 > PEM - Transform p12 format into pem format
openssl pkcs12 -in keystore.p12 -out keystore.pem -nodes
PEM > RSA PRIVATE KEY - Export the private key in RSA format
openssl rsa -in keystore.pem -text > keystore_rsa.pem
And it did work this time.
you must make sure that the certificate, private key, and certificate chain are all PEM-encoded as following:
-----BEGIN CERTIFICATE----- << -This is my Intermediate CA which signed my CSR
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- << -This is my Root CA which signed my Intermediate CA
Base64-encoded certificate
-----END CERTIFICATE-----
You don't need to put your signed certificate in the chain.
Just add the intermediate and root ca in the Chain files should be enough.
Using the folliowing as ca chain certificate solves the problem:
https://ssltools.thawte.com/chainTester/webservice/validatecerts/certificate?certKey=issuer.intermediate.cert.57&fileName=thawte%20DV%20SSL%20CA%20-%20G2&fileExtension=txt
It is important to note that the intermediate certificates are not specific to your domain or certificate. So, every certificate issued that is like yours, has the exact same intermediate certificates.
You can think of them a bit like the routing number on your checks. The routing number is needed, but really says more about your bank than it does about you. Your account number, or your certificate in this case, is what is unique to you.
Because of the generic nature of the intermediate certificates there are websites like this one:
https://www.ssl2buy.com/wiki/ssl-intermediate-and-root-ca-bundle
That have all of the intermediate certificates pre-bundled (and in the correct order) for different certificate issuers.
I'm trying to enable SSL for Boomi webservices. I've followed the instructions on their documentation to generate the CSR and sent it to CA for signing. I've received the signed certificate in .pem format. I've looked at the contents of the file and it doesn't contain any information about any private key.
These are the steps on Boomi's documentation.
1) Replace the keystore path, KEYSTORENAME and –dname parameters in this command with your information (this –dname “….” option can be omitted if the trusted root authority requests this information when submitting the CSR) and run the following command to generate the key:
keytool -genkey -dname "CN=HOSTNAME, OU=ORGUNIT, O=ORG, L=LOCATION, S=STATE, C=COUNTRY" -alias Boomi -keyalg RSA -keystore c:\Certificates\Boomi\KEYSTORENAME -keysize 2048
2) Replace the KEYSTORENAME in this command and run the following command to generate the CSR:
keytool -certreq -keyalg RSA -alias Boomi -file c:\Certificates\Boomi\KEYSTORENAME.csr -keystore c:\Certificates\Boomi\KEYSTORENAME
3) Submit the CSR to the Trusted Root Authority (for example, Verisign), and request/download the returned certificate in PKCS7 format. This will have a public, G3 intermediate, and G5 intermediate certificate all in one certificate. Java must be 1.6 or newer.
4) Replace the certificate file path\name and keystore path\name in this command and run the following command to import the PKCS7 certificate:
keytool -import -alias Boomi -trustcacerts -file c:\Certificates\Boomi\NEWCERTNAME.p7b -keystore c:\Certificates\Boomi\KEYSTORENAME
5) Replace the new and destination keystore paths/names and passwords (if different from changeit) in this command and run the following command to convert to .p12 format for import into Boomi:
keytool -importkeystore -srckeystore c:\Certificates\Boomi\KEYSTORE -destkeystore c:\Certificates\Boomi\KEYSTORENAME.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass changeit -deststorepass changeit -srcalias Boomi -destalias Boomi -srckeypass changeit -destkeypass changeit -noprompt
I'm stuck at step 4 because I don't have the signed certificate in .p7b format. I've searched around for any information about how to convert .pem file to .p7b file, and all of them mention that the .pem file will contain key information along with the certificate information. But since the .pem file that I have doesn't have the key info, how should I go about converting .pem to .p7b and eventually arrive at .p12 cert.
Also, if possible, can you please explain what do these formats mean?
First, check out this ServerFault answer for information on keys and keyformats.
Second, to address your issue, the .pem file may or may not contain private key information. In the case of a signed certificate (signed after submitting CSR to the CA), it typically will not inlcude the private key. In your instructions, the private key exists in the keystore, already. I believe the command in instruction number 4 will import the trustchain (.p7b) into the keystore, so you'll have the public key, private key, and trust chain all in the same [protected] file.
If you don't have the file in the .p7b format, you could request the CA send it to you in .p7b format.
Barring that, the first thing I would try is changing the command to include the .pem file instead of the .p7b file. keytool is pretty smart, and I would think it would figure out what it needed to do to import the .pem instead of the .p7b.
If that doesn't work for some reason, there's more you can do, but things start to get more complicated. I would start with this link. Good luck!
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