I got a .pem file for mongoDB authentication purpose.
The Windows machine hostname TEST001 (I read it by below method) is embedded in the file so that only that machine has the right to communicate with mongoDB.
When I read the subjectAltName in the given .pem file:
C:\Prj\Certs>openssl x509 -noout -ext subjectAltName -in test_mongodb.pem
X509v3 Subject Alternative Name:
DNS:companyABC, DNS:companyABC.TEST.INTER, DNS:TEST001, DNS:TEST001.TEST.INTER
Now, I have another machine hostname is TEST002 and would want it authenticated to the mongoDB as well.
Is that possible to create new .pem based on the given .pem file, by just alter the hostname (subjectAltName)?
I just want to minimize the effort to create completely new .pem file.
Related
I'm trying to test API that requires a client certificate with postman.
Postman app that comes with google chrome built in app works fine as it loads the correct certificate from user local store.
But this built in app will be deprecated soon. I'm trying to get Postman standalone app. I keep getting
403 Invalid client certificate
It requires the certificate to be loaded manually:
Questions:
I only have pfx certificate loaded on to my local certificate store.
How do I generate CRT file and key file off pfx
How do I generate
passphrase
Thanks.
You can convert pfx certificate into cer and key files by using OpenSSL application (Windows installed can be found under https://slproweb.com/products/Win32OpenSSL.html).
Once OpenSSL is installed, run PowerShell and execute the following commands.
openssl pkcs12 -in test.pfx -nocerts -out test.key
You will be asked to provide password to pfx certificate and set passphrase.
Then execute the following commands and provide password to pfx certificate.
openssl pkcs12 -in test.pfx -clcerts -nokeys -out test.crt
In the case above, cer and key files will be stored under user's directory.
How to make connection from mongo-spark connector to mongodb when only TLS/ssl enabled for mongo DB ?
How to pass the uri and collection name in read config to make connection with TLS/ssl enabled mongodb instance?
Thanks in advance ?
To make the ssl connection from Spark to the Mongo server you will need to trust the Mongo certificate, or the CA (certificate authority) that has signed that certificate. This is the most important part, and the trickiest one for me to figure it out.
Spark is a Java application, so it get the certificates from a jks trustStore. you will need to import the Mongo certificate (only the public part) into a trustStore to make it available for spark. To do so:
Get the Mongo certificate: Ask the DBA or the sysadmin who has setup the mongo to provide the certificate to you. Other aproach is to get it with openssl:
$ openssl s_client -connect mongodb:27017
CONNECTED(00000003)
depth=0 C = ES, ST = Madrid, L = Madrid, O = HOME, OU = HOME, CN=mongodb mongo.hostname.local
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=ES/ST=Madrid/L=Madrid/O=COMPANY/OU=AREA/CN=mongo.hostname.local
i:/C=ES/ST=Madrid/L=Madrid/O=COMPANY/OU=AREA/CN=mongo.hostname.localIssuing CA
---
Server certificate
-----BEGIN CERTIFICATE-----
[..... A bunch of base64 text....]
-----END CERTIFICATE-----
Get the part from the -----BEGIN CERTIFICATE----- to -----BEGIN CERTIFICATE----- and save it in a .cert file
Import it into a trustStore
$ keytool -import -file /path/to/your/mongodb.crt -alias mongodb -keystore /path/to/your/trustStore.jks
Enter keystore password: 123456
...
...
Trust this certificate? [no]: yes
Certificate was added to keystore
Make sure the keystore is accesible from all your spark cluster nodes.
Now, you have your server certificate imported. If you need mutual TLS you will need to provide a valid client certificate. This certificate, and the certificate private key, should be in a jks keyStore (it could be in the same trustStore file you have stored the Mongo server certificate because it uses the same format). If are not going to use mutual TLS you don't need to do this, but you have to check that the MongoDB instance is able to accept connections without client certificates. This is with the flag sslAllowConnectionsWithoutCertificates
The next step is specifying in the connection URI that you want to use TLS. This is fairly simple, just add the ?ssl=true to your connection string. So the connection URI will be something like this
mongodb://user:pw#host:port/db.collection?ssl=true
Now you can summit your job. When summiting the job we also need to specify the location of our trustStore, and the libraries for the mongo connector:
/spark/bin/spark-submit \
--master spark://spark-master:7077 \
--packages org.mongodb.spark:mongo-spark-connector_2.11:2.2.0 \
--conf spark.executor.extraJavaOptions="-Djavax.net.ssl.trustStore=/path/to/your/trustStore.jks -Djavax.net.ssl.trustStorePassword=yourPassword" \
--conf spark.driver.extraJavaOptions="-Djavax.net.ssl.trustStore=/path/to/your/trustStore.jks -Djavax.net.ssl.trustStorePassword=yourPassword" \
/yourJob.jar
We use the extraJavaOptions for the driver and the executor to pass these parameters. If you are using mutual TLS, include the following extra java options:
-Djavax.net.ssl.keyStore=/path/to/your/keyStore.jks
-Djavax.net.ssl.keyStorePassword=yourPassword
The /path/to/your/keyStore.jks is where you have stored your client certificates.
If the spark connector library is not already installed, you may run into trouble. The spark process will go to maven to download the library, but it will not be able to verify the maven certificates because we have specified another keyStore with just our certificate. One workaround is to import our certificate directly into the default keystore located at $JAVA_HOME/jre/lib/security/cacerts. The default password is changeit. Remember to do this in every worker node too.
I hope it helps!
Sources:
https://github.com/brunocfnba/spark-mongo-ssl
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.5.5/bk_spark-component-guide/content/spark-encryption.html
https://community.hortonworks.com/articles/147113/how-to-configure-your-spark-application-to-use-mon.html
https://mapr.com/support/s/article/Unable-to-find-valid-certification-path-to-requested-target-error-while-accessing?language=en_US
I have created CSR using openssl and I want it to be signed by the Microsoft CA using command line with template as webServer.
This is the way to generate. Got it! .. On a Microsoft CA server machine issue below command:
"certreq.exe -submit -attrib "CertificateTemplate:WebServer" certifcatesigningrequest.csr "
I am trying to connect to RDS running on AWS (Amazon Web Services) using SSL. I saw limited info in PosgreSQL pgAdmin III docs about fields on SSL tab.
RDS instances are setup to accept SSL connections by default.
I've downloaded the public key from Amazon and converted it from a .pem to a .crt file using openSSL. On the SSL tab in pgAdmin III I entered path to converted key file "Server Root Certificate File" field.
I can connect to instance without issue but there is no indication that the data is being transferred over SSL. AWS does not set their RDS instances to use SSL exclusivly so I may be connected without using SSL and not know it.
Does pgAdmin III show any indication when it's connected using SSL (like a lock icon)?
Can anyone provide additional info that describes the fields (SSL dropdown, Client Cert File, Client Key) on the SSL tab in pgAdmin III?
Thanks.
I have not used SSL with PGAdmin on AWS, but I have on a server, and I can tell you that you know when you are connected to a server via PGAdmin, I'm not sure how there is ambiguity there, can you see the databases, tables?
The quoted post below might help you with connecting to a server via SSL.
On the client, we need three files. For Windows, these files must be
in %appdata%\postgresql\ directory. For Linux ~/.postgresql/
directory. root.crt (trusted root certificate) postgresql.crt (client
certificate) postgresql.key (private key)
Generate the the needed files on the server machine, and then copy
them to the client. We'll generate the needed files in the /tmp/
directory.
First create the private key postgresql.key for the client machine,
and remove the passphrase.
openssl genrsa -des3 -out /tmp/postgresql.key 1024
openssl rsa -in /tmp/postgresql.key -out /tmp/postgresql.key
Then create the certificate postgresql.crt. It must be signed by our
trusted root (which is using the private key file on the server
machine). Also, the certificate common name (CN) must be set to the
database user name we'll connect as.
openssl req -new -key /tmp/postgresql.key -out /tmp/postgresql.csr -subj '/C=CA/ST=British Columbia/L=Comox/O=TheBrain.ca/CN=www-data'
openssl x509 -req -in /tmp/postgresql.csr -CA root.crt -CAkey server.key -out /tmp/postgresql.crt -CAcreateserial
Copy the three files we created from the server /tmp/ directory to the
client machine.
Copy the trusted root certificate root.crt from the server machine to
the client machine (for Windows pgadmin %appdata%\postgresql\ or for
Linux pgadmin ~/.postgresql/). Change the file permission of
postgresql.key to restrict access to just you (probably not needed on
Windows as the restricted access is already inherited). Remove the
files from the server /tmp/ directory.
From: http://www.howtoforge.com/postgresql-ssl-certificates
First, login as your postgresql admin user then run the following to install sslinfo on RDS:
create extension sslinfo;
To verify if you're connected via ssl simply run the following query in your session:
select ssl_is_used();
If it returns true (t), then you're connected via SSL.
I am attempting to authenticate to the Intuit API Explorer to become better acquainted with the Customer Data (AggCat) API.
I enter the Consumer Key/Secret, SAML id, user ID, and the original .crt certificate that I uploaded. I get the error:
The given certificate file is not supported. Please provide valid PEM certificate file.
I don't understand this error, because the .crt file is PEM-encoded, as far as I can tell.
Nevertheless, I went to the 'Create X.509 keys' page:
http://docs.developer.intuit.com/0020_Aggregation_Categorization_Apps/009_Using_AggCat/0010_GettingStarted/0015_Create_an_AggCat_integration/0010_Creating_X.509_Public_Certificates
and followed the instructions at the bottom 'Generating a PEM file'. I am able to get past step 1. (convert jks store to p12 format), but I get the following error when attempting to run step2:
$ openssl pkcs12 -in keystore.p12 -nocerts -out cert.pem
MAC verified OK
Error outputting keys and certificates
139679448614560:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
139679448614560:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error:p12_decr.c:104:
139679448614560:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:p12_decr.c:130:
I am using jdk-1.7.0_17 and openssl-1.0.1 on ubuntu-12.04 LTS.
Thanks for any help.
Found it, stop looking!
The problem arises from the fact that the PKCS12 format does not support separate passwords for the storage file and any keys inside it. Both the storage file and the key inside it have to be encrypted with the same password.
So the easiest was to go through the process again, and in the step of generating the initial private key and keystore with keytool:
keytool -genkey -alias myapp -validity 1095 -keyalg RSA -keystore keystore.jks
make sure to use the same password for both the keystore (storepass) and the private key (keypass).
As an alternative, if you really must/want to use separate passwords for the keystore and key in that step, in the initial step for creating the PEM:
keytool -importkeystore -srckeystore [MY_KEYSTORE.jks]
-destkeystore [MY_FILE.p12]
-deststoretype PKCS12
-deststorepass [PASSWORD_PKCS12] change this to [KEYPASS]
-srcstorepass [PASSWORD_JKS]
set the -srcstorepass to the password of the keystore (storepass), but set the
-deststorepass of the PKCS12 file to the password of the private key (keypass) used when creating the key/keystore via the keytool -genkey command further above.
I have not tested this alternative, but it should work as well, since both the PCKS12 store and the key would end up using the same password.