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.
Related
I am trying to setup 2 way ssl authentication. My requirement is broker should authenticate only specific clients.
My organization has a CA which issue all certificates in pkcs12 format. steps i followed are as follows.
get a certificate for the broker and configured it in the broker keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
ssl.client.auth=required
get a certificate for the client and configured it in the client keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
extracted the public certificate from the client certificate using keytool command
keytool -export -file cert -keystore certificate.p12 -alias "12345" -storetype pkcs12 -storepass xxxxx
imported the certificate into broker truststore. broker truststore contains only the client 12345 certificate.
keytool -keystore truststore.p12 -import -file cert -alias 12345 -storetype pkcs12 -storepass xxxxx -noprompt
configured the truststore in the broker.
ssl.truststore.location=/home/kafka/truststore.p12
ssl.truststore.password=xxxxx
configured the truststore in client. client truststore contains CA certificates.
ssl.truststore.location=/etc/pki/java/cacerts
ssl.truststore.password=xxxxx
When i run the broker and client i expect the broker to authenticate the client and establish ssl connection. but instead following error is thrown.
[2021-06-03 23:32:06,864] ERROR [AdminClient clientId=adminclient-1] Connection to node -1 (abc.com/10.129.140.212:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
[2021-06-03 23:32:06,866] WARN [AdminClient clientId=adminclient-1] Metadata update failed due to authentication error (org.apache.kafka.clients.admin.internals.AdminMetadataManager)
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLProtocolException: Unexpected handshake message: server_hello
I tried various things but nothing seems to work. when i replace the broker truststore with /etc/pki/java/cacerts truststore file which contains only the CA certificate
then it works fine. but it will authenticate any client which has certificate issued by the CA.
what could be the issue ?
The default format is jks,
use keytool to create a Java KeyStore (JKS) with the certificate and key for use by Kafka. You'll be prompted to create a new password for the resulting file as well as enter the password for the PKCS12 file from the previous step. Hang onto the new JKS password for use in configuration below.
$ keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12 -alias myserver.internal.net
Note: It's safe to ignore the following warning from keytool.
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12"
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.
Right now I am securing my installation of ElasticSearch using SSL.
In the guide they mention to secure the endpoint by importing an x.509 certificate using the following keytool command:
keytool -importcert -keystore node01.jks -file cacert.pem -alias my_ca
The problem is that I have a .pfx file generated by a CA authority. If I pass the .pfx file keytool bombs saying
Input not an X.509 certificate.
How can I fix this, is there a way to convert the .pfx into a .pem certificate?
You can do so easily using the following command:
openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes
You can also name the output certificate certificate.pem if you wish. PEM certificates can usually have any of the following extentions: .pem, .crt, .cer, and .key
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 been struggling for the last three hours trying to create an .pfx file using OpenSSL. I have been following this document and have been following the instructions under the Get a certificate using OpenSSL header.
I am at the step here: openssl pkcs12 -export -out myserver.pfx -inkey myserver.key -in myserver.crt and am using the OpenSSL.exe console.
I get the error: unable to load certificates
I have also tried this: x509 -text -in myserver.key and received the error: 0906D06D06C:PEM_read_bio:no start line:.\crypto\pem\pem_lib.b.c:703:Expecting: TRUSTED CERTIFICATE I also get that error if I try myserver.crt.
I seem to get it no matter what I do.
Can someone please help?
I get the error: unable to load certificates
myserver.crt needs to be in PEM format. Does it have ----- BEGIN CERTIFICATE ----- and ----- END CERTIFICATE -----?
myserver.crt should actually be a chain of certificates (and not just the one server certificate). The chain should include all intermediate certificates needed by the client to verify the chain.
You send all the intermediate certificates to solve the "which directory" problem. The "which directory" is a well know problem in PKI. Essentially, the client does not know where to go to fetch the missing intermediate cert. To avoid the problem, you send all intermediates.
I often use Startcom because they offer free Class 1 certificates. When I get the signed server certificate from them (for example, www-example-com.crt), I add their Class 1 Server Intermediate to it. I get their Class 1 Server Intermediate from their website at Startcom CA certs. The one I use is sub.class1.server.ca.pem.
With the www-example-com.crt, my server certificate looks like:
$ cat www-example-com.crt
-----BEGIN CERTIFICATE-----
< My Server Certificate >
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
< Startcom Intermediate >
-----END CERTIFICATE-----
For completeness, the private key (for example, www-example-com.key) is also in PEM format. It uses -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY-----.
With my server certificate in PEM format (and with the required intermediates) and private key, I then issue the following (which looks like the same command you are using):
openssl pkcs12 -export -in www-example-com.crt -inkey www-example-com.key -out www-example-com.p12
When clients connect, they use the Startcom CA. So, to test the connection (after loading into IIS):
openssl s_client -connect www.example.com:443 -CAfile startcom-ca.pem
The command should complete with "Verify OK":
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 37E5AF0EE1745AB2...
Session-ID-ctx:
Master-Key: 7B9F8A79D3CC3A41...
Key-Arg : None
Start Time: 1243051912
Timeout : 300 (sec)
Verify return code: 0 (ok)
I have also tried this: x509 -text -in myserver.key and received the error...
x509 is for certificates. If you want to dump a key, use OpenSSL's pkey command. See the docs on OpenSSL's pkey(1) command.
keytool -importcert -alias yourdns -keystore /usr/lib/jvm/java-11-openjdk-11.0.15.0.9-2.el7_9.x86_64/lib/security/cacerts -file pathcertificate/.crc
password default = changeit