I am trying to establish node to node encryption. I am following datastax online guidance available for ssl encryption on below link- https://docs.datastax.com/en/security/5.1/security/secSetUpSSLCert.html
as per the documentation i have skipped first two steps and followed from step-3.
so, I have created the keystore, using below command-
keytool -genkeypair -keyalg RSA -alias node1 -keystore cassandra.jks -storepass cass123 -keypass cass123 -validity 365 -keysize 2048 -dname "CN=host1, OU=cluster1, O=org, C=US"
after creating the keystore, here the public certificate authority have two level of encryption or certs. first is root.cert and another is intermediate.cert.
when i have checked through below command, intermediate.cert is signed or verifyed by root.cert.
openssl verify -CAfile root.cert intermediate.cert , Got OK in Response.
after than with keystore(cassandra.jks), i have raise the certificate signed request (CSR):
keytool -keystore cassandra.jks -alias node1 -certreq -file cassandra.csr -keypass cass123 -storepass cass123 -dname "CN=host1, OU=cluster1, O=org, C=US"
then after uploading this CSR file (cassandra.csr) to public certificate authority i got in response one Cert.cer file.
so, then i checked whether the Cert.cer file get signed by root.cert or not.
openssl verify -CAfile root.cert Cert.cer
Got unable to load certificate in Response, with error message-
140044398696338:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c707:Expecting TRUSTED CERTIFICATE
Even I have Checked the Cert.cer with intermediate.cert-- got the same above error message.
Is this mean the Cert.cer which i got in response to csr request in not properly signed by certificate authority.
So i have stopped further steps here, which needed for cassandra ssl implementation.
Please, let me know, if i miss something or doing in wrong manner. much appreciated all help and suggestions
This issue is resolved, due to platform issue certs generated have extras carriage characters ^M. after removing this and merging root and intermediate certs together it works fine.
Related
I have generated the CSR request on our wintel server ( we need to bind our application hosted on this server for Https) using below commands in keytool:
Keytool -genkey -alias <server name> -keyalg RSA -keysize 2048 -keystore <server name>.keystore
Enter keystore password - changeit
Confirm the password – changeit
Common Name: ******
Organization: ***
Organization Unit: **
Locality: ****
State: ***
Country: **
Enter key password or hit enter to keep same as keystore password
keytool -certreq -keyalg RSA -alias <server name> -file certreq.csr -keystore <server name>.keystore
Two files are generated
certreq.cer
.keystore
I send the two files to the concerned team, they got the SSL certificate and installed it on the same server.
Now the certificate is there in console root\certificates (local computer)\personal\certificates but its not appearing in IIS for binding. The team is now asking me for the private key to resolve the issue.
Can someone let me how to get the private key from the .cer and .keystore file?
And if you can point out the reason why certificate is not appearing in IIS and how to resolve it, I would really appreacite that.
P.S: I am not sure if this is the right place for this question. Help me out to know the right place if this is not.
Edit: For someone stuck with same questions, check out the answer
by garethTheRed here- https://serverfault.com/questions/943496/how-to-install-cer-and-p7b-certificates-to-use-in-iis/943500#943500
In my case, the certificate received from CA was directly installed, thats why it was not private key verified, and was not appearing in IIS also. We had to import the public key(the .cer file) to the keystore
keytool -importcert -file certificate.cer -keystore <server name>.keystore -alias <server name>
and then convert the keystore to a PKCS#12, with:
keytool -importkeystore -srckeystore <server name>.keystore -destkeystore <server name>.pfx -srcstoretype JKS - deststoretype PKCS12 -deststorepass <new password>
Then we imported the pfx in certificate store.
I have the working GoDaddy SSL certificate for Java/Tomcat server, consisting of 3 files:
a6d8a8b6f1b7d24b.crt
gdig2.crt.pem
gd_bundle-g2-g1.crt
All three are the base64 encoded text files and the contents look like
-----BEGIN CERTIFICATE-----
MIIFNjCCBB6gAwIBAgIJAKbYqLbxt9JLMA0GCSqGSIb3DQEBCwUAMIG0MQswCQYD
...
MLLO84KBeOlWOD9ShSj2OqPQiozGPPjqzuIyyWJF37s0Y/BpgJPfqHgE
-----END CERTIFICATE-----
gd_bundle-g2-g1.crt contains multiple such entries inside.
Now, Hyperledger instructions here explain:
composer-rest-server -t -c /tmp/cert.pem -k /tmp/key.pem -p hlfv1 -n my-network -i alice1 -s suchs3cret
Which one in my case is expected to be the cert.pem and which one the key.pem? Do they need any conversion, and if they do, how? These certificates work fine for Java frameworks that use jks keystore. Hyperledger uses node.js and produces errors like
Error: error:0906D06C:PEM routines:PEM_read_bio:no start line
at Error (native)
at Object.createSecureContext (_tls_common.js:85:17)
at Server (_tls_wrap.js:776:25)
at new Server (https.js:26:14)
at Object.exports.createServer (https.js:47:10)
at Promise.then (/home/hla/.nvm/versions/node/v6.11.2/lib/node_modules/composer-rest-server/server/server.js:148:28)
at process._tickCallback (internal/process/next_tick.js:109:7)
I tried to substitute the files in various combinations but only get error messages so far. I think I actually tried all possible combinations already, so very likely the format is wrong.
GoDaddy allows to export certificates also in various popular formats (Apache, Exchange, IIS, MacOS X and Tomcat to be precise), but Hyperledger is obviously not between them.
It may also be problematic that when I generate the certificate with
openssl req -newkey rsa:2048 -new -nodes -keyout key.pem -out csr.pem
(where obviously key.pem should probably be the key), I also get the same error:
Error: error:0906D06C:PEM routines:PEM_read_bio:no start line
OpenSSL version OpenSSL 1.0.2g 1 Mar 2016. node --version. node --version. node --version 5.4.0.
The rest server is expecting 2 things in order to be able to enable tls. It requires a private key and a public certificate associated with that private key. They both need to be in .pem format. The public certificate will have text that starts with -----BEGIN CERTIFICATE----- whilst the private key will have text that starts with -----BEGIN PRIVATE KEY-----
The openssl command can be used to generate a self signed certificate for example which would be usable by the rest server. In the example you gave above, you actually generated a CSR (certificate request) which is a request to create a certificate for you based on the private key it has generated and so the csr.pem file it created isn't a usable certificate. A CSR is something you send to a certificate authority to request the creation of a certificate.
Use gdig2.crt.pem as your certificate (-c). You need to specify the file to your private key (-k) which you used to generate the CSR. If your private key is password protected, you need to provide the passphrase in composer-rest-server/server.js (look for the line https.createServer({cert, key}, app);). Good luck.
Following the go-daddy documentation :
https://www.godaddy.com/help/tomcat-4x5x6x-renew-a-certificate-5355
The flow:
I've create myDomain.csr and send it to GoDaddy , got reply from them with 3 files ( gd_bundle-g2-g1.crt , gdig2.crt.pem ,59a41eaec32d2046.crt)
I mentioned that the old cert which was expired has a chain structure , unfortunately Go-daddy give me only "flat" certificates.
I tried to make a chain by myself :
cat 59a41eaec32d2046.crt gd_bundle-g2-g1.crt gdig2.crt.pem >> myDomain.crt
after that :
sudo keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file myDomain.crt
sudo keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gdig2.crt
sudo keytool -import -alias root -keystore tomcat.keystore -trustcacerts -file gd_bundle-g2-g1.crt
and change the server.xml exactly as in the documentation
I Attach pictures of how in my opinion it should appear
But Actually after my chain I had :
When I open the Browser GOT:
Secure Connection Failed
An error occurred during a connection to talenttribe.me. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Learn more…
Report errors like this to help Mozilla identify and block malicious sites
Don't understand what I'm missing...is it Chain creation or tomcat issues ??
BR,
You just need to replace tomcat certificate if your renew from existing vendor.
certificate name hexcode.crt Other no need to change. Its works for me.
keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file filepath
The issue is that the tomcat.keystore is not being created with chaining intact. To correct that, you will need to isolate the root and intermediate certificates in separate files, and then import them in a specific order. To create a working example, here are some simplifying assumptions:
The 59a41eaec32d2046.crt file contains only the SSL certificate issued by Go Daddy, presumably for an internet facing web server.
The "gd_bundle-g2-g1.crt" file is a concatenation of the Go Daddy intermediate and root certificates.
The "gdig2.crt.pem" file contains a redundant copy of the Go Daddy root certificate.
There is only one intermediate certificate, and it is also the Issuer of your SSL certificate.
The crt files are the base 64 encoded, or "pem", format.
The tomcat.keystore file uses JKS format.
Here are the steps to create the tomcat.keystore, given the assumptions above:
List the contents of gd_bundle-g2-g1.crt:
sudo keytool -printcert -file gd_bundle-g2-g1.crt
The output will include delimiters for each certificate in the bundle. The delimiter for the first certificate will be "Certificate[1]:", and the delimiter of the second certificate will be "Certificate[2]:". Immediately following "Certificate[1]:", you will see the Owner and Issuer records for the first certificate. Likewise, following "Certificate[2]:", you will see the Owner and Issuer records for the second certificate. Also note:
The root certificate is unique in that the Owner is the same as the Issuer (in other words, it is self-signed).
The root certificate is also the Issuer of the intermediate certificate.
List the contents of gd_bundle-g2-g1.crt in "rfc" format:
sudo keytool -printcert -file gd_bundle-g2-g1.crt -rfc
Again, note the delimiters "Certificate[1]:" and "Certificate[2]:" are used with the same meaning as above. But in rfc format, the certificates are listed using base 64 "pem" format starting with "-----BEGIN CERTIFICATE-----" and ending with "-----END CERTIFICATE-----". That is format that will be needed in the separate root and intermediate certificate files.
Redirect the output of step 2 to a temporary file. Then use a text editor to save the Go Daddy root certificate in a separate file named gd_root.crt.
Be certain to include the entirety of the text beginning with "-----BEGIN CERTIFICATE-----" and ending with "-----END CERTIFICATE-----".
Likewise, save the Go Daddy intermediate certificate in a separate file named gd_intermediate.crt.
Use the "keytool -importcert" command to create the keystore incrementally:
sudo keytool -importcert -noprompt -file gd_intermediate.crt -alias intermed -keystore tomcat.keystore -storepass '!q#wDDfll'
sudo keytool -importcert -noprompt -file gd_root.crt -alias root -keystore tomcat.keystore -storepass '!q#wDDfll'
sudo keytool -importcert -noprompt -file 59a41eaec32d2046.crt -alias tomcat -keystore tomcat.keystore -storepass '!q#wDDfll'
The order of the commands above is important. You need to create the keystore first using the intermediate certificate used by the CA to issue (sign) your SSL certificate. (If there are additional intermediate certificates, those would be added next, until the final intermediate certificate, which is signed by the root certificate, is added.) Next, you add the root certificate. And finally, you add the SSL certificate issued by the CA for your application.
This will fix the issue with the tomcat.keystore file. You might also consider building a custom trust store file, which requires the truststoreFile and truststorePass options within the connector element, as an alternative to relying on Java's cacerts trust store. The commands to do that are similar to the fist 2 commands above, substituting the trust store file name along with the trust store password.
I'm facing an issue in installing SSL certificate in IIS and below are the step before I got the certificate from my CA.
Generated a private key file using OpenSSL with: "openssl genrsa -out key_name.key 2048" command.
Generated .csr file with: "openssl req -out CSR.csr -key key_name.key -new -sha256" command.
Once I generated the CSR file, I provided the same CSR file to CA to get me certificate.
I got the certificate in .p7b format, which I converted to .cer format.
Installed certificate using "Complete certificate request" option in IIS.
Now the problem is that newly installed certificate vanishes from IIS after a refresh. I Googled this issue and understood that, it's happening so because there is no private key associated with certificate. My question is where the private key has gone?? I had created the CSR using the private key in step 1. Secondly, how do I over come this issue, I have to install the certificate anyhow. Please help.
You did not generate the certificate request via IIS Manager. Thus, you should not use IIS to complete the request.
Instead, you need to use OpenSSL to generate a PFX file,
create a pfx file from a .cer and a .pem file
Then you can import it to IIS.
You might read this post for more details,
https://blog.lextudio.com/2015/06/the-whole-story-of-server-certificate-disappears-in-iis-77-588-510-0-after-installing-it-why/
Created Private Key & Self signed certficate in a Key Store
keytool -genkey -alias mydomain -keystore mydomain.ks -dname cn=mydomain.com -keyalg RSA -sigalg SHA1withRSA
Created Certificate Request and sent to Internal CA
keytool -certreq -alias mydomain -keystore mydomain.ks -file mydomain_project.csr
Once Internal(Company) CA issues the certificate - which looks like something like this
e.g.
-----BEGIN CERTIFICATE-----
MIAGCSqGSIb3DQEHAqCAMIACAQExADALBgkqhkiG9w0BBwGggDCCAmowggHXAhAF
UbM77e50M63v1Z2A/5O5MA0GCSqGSIb3DQEOBAUAMF8xCzAJBgNVBAYTAlVTMSAw
E+cFEpf0WForA+eRP6XraWw8rTN8102zGrcJgg4P6XVS4l39+l5aCEGGbauLP5W6
-----END CERTIFICATE-----
Copied this to a .pem file
Update the self signed certifcate in (identity) KeyStore with CA signed certificate & Created a new Java Key Store(Trust) CA signed certificate(using the .pem file)
keytool -import -alias mydomain -trustcacerts -file company_cert.pem -keystore mydomain.ks
keytool -import -alias mydomain -trustcacerts -file company_cert.pem -keystore trust.jks
On Weblogic I imported the keystores as follows and Enabled SSL.
Identity - mydomain.ks (with Private Key + CA certificate)
Trust - trust.jks (which has CA certificate)
Issue: Once I hit my internal site deployed on the weblogic. I get a message - Not a trusted certificate.
I then download the certifcate from the browser only then https works.but the certificate shows it is signed bythe domain name I gave, instead of my Internal CA name.
Question: I expected it to work(with out actually downloading again) as I already have Internal CA certificates and other internal applications work on https. Did I do any thing wrong?
I am not sure how/where you imported the certificate as you say but the browser has a different truststore than java.
So you have to add it as an exception to its truststore the first time you access the site.
As far as the domain name that is displayed the browser pops up the certificate as send by the server
I solved my problem. Thanks user384706.
Basically once you get a signed .pem file(with START & END) from CA.
Before you import this signed certificate to replace the self-signed in your keystore(Identity Keystore to be configured on WebLogic). We need to make sure
1) CA root certificates(Verisign's or your company signed CA certificates) are imported to the same Keystore. You can find CA root certs on your windows box (run-certmgr.msc).
2) Also make sure that all these alias names are the same -
self-signed cert
cert request
while importing CA cert