I am new to SSL setup, please excuse me if my question is wrong.
I have deployed a Spring Boot application on AWS EC2 (Windows) instance with bunch of restful services, exposed through public IP address (AWS), i am able to access them publicly(http). I want to SSL(https) them now. I am in process of purchasing certificate, in one of the steps to setup, they have given these lines to validate a text file, is anyone aware of this ? Can you please suggest where i need to create ./well-known/pki-validation folder on my Spring Boot application(Tomcat) ?
The issuing vendor will provide you with a simple text-based file to place in sub-folders /.well-known/pki-validation/ in your site’s "home directory". If done properly, the vendor can view this file via HTTP:// and then issue the certificate upon confirmation.
1 Install certboot in the server.
git clone https://github.com/certbot/certbot
cd certbot
./certbot-auto --help
2 Obtain the certificate
In order to obtain the certificate you need to expose trough the server certain files. I do that using the target folder of spring boot tomcat.
./certbot-auto certonly --webroot -w {SpringBootProjectDir}/target/classes/static/ -d {yourDomain.com}
This command obtains the certificates and leaves them in:
/etc/letsencrypt/live/{yourDomain.com}/
Tomcat can't read the certificate provided since its not in p12 format. We have to generate the cert in this format. Use this command
sudo openssl pkcs12 -export -in /etc/letsencrypt/live/{yourDomain.com}/fullchain.pem -inkey /etc/letsencrypt/live/{yourDomain.com}/privkey.pem -out /etc/letsencrypt/live/{yourDomain.com}/keystore.p12 -name tomcat -CAfile /etc/letsencrypt/live/{yourDomain.com}/chain.pem -caname root
It will ask you a password. Keep the password.
3 Configure the server
server.port=443
server.ssl.enabled=true
server.ssl.key-store: /etc/letsencrypt/live/{yourDomain.com}/keystore.p12
server.ssl.key-store-password: {password}
server.ssl.keyStoreType: PKCS12
server.ssl.keyAlias: tomcat
Restart the server and Thats it!
Related
We have a superset docker containers which is using keycloak as identity broker. All this setup is working fine on http. Further, we have installed ssl certificate on keycloak and same is also working fine. Our superset and keycloak integration code changes look exactly like its mentioned in the answer here.
Now, when we changed auth uris from http to https in superset/docker/pythonpath_dev/client_secret.json, we are getting below error after the login flow is redirected from keycloak to superset.
Forbidden
'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1091)'
We also tried installing root certificates on superset by mounting them on /usr/local/share/ca-certificates and then executing update-ca-certificates in the container, but still there was no help. Any idea how this can be resolved?
Thanks #sventorben for the tip. Indeed it was python which was not able to read my ca files. Since I am new to this, I would detail out all the steps followed. However, some of these steps might be redundant.
After I received my root as well intermediary CA files, I first converted them to PEM format as they were in DER format using openssl.
openssl x509 -inform DER -in myintermediary.cer -out myintermediary.crt
openssl x509 -inform DER -in myroot.cer -out myroot.crt
Then, I mounted these files to my superset container at path /usr/local/share/ca-certificates/
Then, I logged into my container and executed update-ca-certificates command and verified that 2 new pem files got added at /etc/ss/certs/ path i.e. myroot.pem and intermediary.pem.
Then, I added these CA files to python certifi inside my container. To find out the path of cacert.pem, I executed below commands into python terminal.
import certifi
certifi.where()
exit()
Here, second command gave me the path of cacert.pem which was like /usr/local/lib/python3.7/site-pacakges/certifi/cacert.pem.
After this, i appended my ca files at the end of cacert.pem
cat /etc/ssl/certs/myroot.pem /etc/ssl/certs/intermediary.pem >> /usr/local/lib/python3.7/site-pacakges/certifi/cacert.pem
In the end i logged out of my container and restarted it.
docker-compose stop
docker-compose up -d
Note:
I feel step 3 is redundant as python does not read CA files from there. However, i still did it and I am in no mood of reverting and test it out again.
Also, this was my temporary fix as executing the commands inside the container is not useful as they are ephermal.
Update:
Below are the steps followed for production deployment.
Convert root certificates in PEM format using openssl.
Concat both PEM files into a new PEM file which will be installed as bundle. Lets say, the new PEM file is mycacert.pem and same is mounted at /app/docker/.
Create one sh file called start.sh and write 2 commands as below.
cat /app/docker/mycacert.pem >> /usr/local/lib/python3.7/site-pacakges/certifi/cacert.pem
gunicorn --bind 0.0.0.0:8088 --access-logfile - --error-logfile - --workers 5 --worker-class gthread --threads 4 --timeout 200 --limit-request-line 4094 --limit-request-field_size 8190 'superset.app:create_app()'
Modify docker-compose.yml and change command as below.
command: ["/app/docker/start.sh"]
Restart superset container.
docker-compose stop
docker-compose up -d
My domain is: https://www.neasy.de
I ran this command:
git clone https://github.com/certbot/certbot
cd certbot
./certbot-auto certonly -a standalone -d neasy.de -d www.neasy.de
cd /etc/letsencrypt/live/neasy.de
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out keystore.p12 -name tomcat -CAfile chain.pem -caname root
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version): linux
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):certbot 0.31.0
4 month ago i first used letsencrypt and I was success to use it. I learned I have to generate certificate
with and without www. prefix and it is important. My company has changed the domain name from neasy.app to neasy.de and for that I deleted my old certificate and generate new one for neasy.de
Now i am in a new trouble that if i write in my browser neasy.de it does not work even if i write www.neasy.de it does not work. But for at least once time if I write https://neasy.de or https://www.neasy.de it works, and for the next time i dont need to write https:// prefix.
This issue really seems weird to me any help will be appreciated. If you already tried writting https://neasy.de then you can open firefox browser private window
Since you're using Ubuntu please follow this guide:
https://certbot.eff.org/lets-encrypt/ubuntuxenial-apache.html (jus make sure to choose your ubuntu release from the dropdown).
this will guide you through the whole process without manual work.
Just make sure to run all apt-related commands.
Was there a route for the old domain neasy.app which was redirecting the http traffic to https ? It looks like you forgot to update that route with the new domain name.
Usually when you enter any new website in the address bar of browser it by default uses http protocol. On the server site you have to do a 301 redirect from http to https.
By default setting up Solr on Https requires storing the certificate password as plain text in "bin\solr.in.cmd" (using windows to host solr)
And the certificate password is exposed in the portal.
How can I configure Solr with a Https certificate keeping the certificate password safe?
I want to use a private certifcate so the client trusts the certificate by default, rather than a self signed one.
I'm connecting via SolrNet from C#, currently without authentiation, but in the future can look at Basic Authentication which is supported in the provider which wraps SolrNet.
Seems like a basic thing which I would have thought should be supported? Can't find any article/documention on this.
Anyone solved this already?
Nearest I've found is:
Setting SOLR SSL properties
http://lucene.472066.n3.nabble.com/Prevent-the-SSL-Keystore-and-Truststore-password-from-showing-up-in-the-Solr-Admin-and-Linux-process-td4257422.html
Some suggestion of using jetty-https.xml and encrypt the configuration there.
Looking for a more complete answer.
update
I've come across the following Solr tickets:
https://issues.apache.org/jira/browse/SOLR-10307
https://issues.apache.org/jira/browse/SOLR-8897
Where support for loading the certificate passwords from environment variables has been added in Solr 7.0 and 6.7 (which hasn't been released yet).
I don't think using environment variables is much better, but some progress.
There is also a link to using Hadoop credential provider, but I'm not using Hadoop, so not applicable for me.
In the comments of the tickets, it mentions that someone tried the Jetty Password Utility, and Solr UI loaded over HTTPS. However the Collection API was erroring not being able to understand the password format.
So I'm still left without a way of configuring a certificate password for Solr, in a way I feel is secure.
For me the certificate password is not stored on the SOLR portal
see my setup
SSL
cd /path/to/solr/server/etc/
The following command will create a keystore file named solr-ssl.keystore.jks in the current directory
keytool -genkeypair -alias solr-ssl -keyalg RSA -keysize 2048 -keypass secret -storepass secret -validity 9999 -keystore solr-ssl.keystore.jks -ext SAN=DNS:localhost,IP:#ipsolr,IP:127.0.0.1 -dname "CN=localhost, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx"
Convert the certificate and key to PEM format for use with Curl
keytool -importkeystore -srckeystore solr-ssl.keystore.jks -destkeystore solr-ssl.keystore.p12 -srcstoretype jks -deststoretype pkcs12
Next convert the PKCS12 format keystore into PEM format using the openssl
openssl pkcs12 -in solr-ssl.keystore.p12 -out solr-ssl.pem
After go to your $JAVA_HOME (into jre/lib/security)
curl --cacert /pah/to/solr/server/etc/solr-ssl.pem https://localhost:8983/solr/
Set Common SSL-Related System Properties
vi /etc/default/solr.in.sh
SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_KEY_STORE_PASSWORD=secret
SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_TRUST_STORE_PASSWORD=secret
SOLR_SSL_NEED_CLIENT_AUTH=false
SOLR_SSL_WANT_CLIENT_AUTH=false
SOLR_SSL_KEY_STORE_TYPE=JKS
SOLR_SSL_TRUST_STORE_TYPE=JKS
Restart solr
service solr restart
For authentication
create security.json on SOLR_HOME (/var/solr/data/ for me)
Owner : root
See example of security.json to configure has you hope
After securing, add into solr.in.sh
SOLR_AUTH_TYPE="basic"
SOLR_AUTHENTICATION_OPTS="-Dbasicauth=solr:xxx"
it allows to have an answer on solr status service because with authentication it is not accessible
For me it's work and i don't see the certificate password on solr UI
Well, My problem starts with Google Maps API. Working local everything is fine, but When i published my system in web (Digital Ocean Host) i discovered that Google Maps API only works with HTTPS protocol.
So, searching in the internet i found the https://letsencrypt.org/ , a good way to use HTTPS without pay, beacause i'm justing testing, not production yet.
But i'm using a JBOSS EAP 7 and i didn't found any tutorial in letsencrypt.org to JBOSS, so i found this link: https://knowles.co.za/creating-renewing-a-lets-encrypt-certificate-for-apache-and-wildfly/.
Following the WildFly tutorial i tried execute this step:
sudo openssl pkcs12 -export -in /etc/letsencrypt/live/YOURDOMAIN/fullchain.pem -inkey /etc/letsencrypt/live/YOURDOMAIN/privkey.pem -out YOURKEYSTORENAME.p12 -name KEYSTOREALIAS
PS: I changed the YOURDOMAIN to my domain.
I got the following error:
No such file or directory fullchain.pem
This file didn't should be created automatically ?
I am setting up a HTTPS server using Spring boot. I followed the Configure SSL on Spring Boot Docs.
My application.properties file is as follows.
# SSL
server.port = 8443
server.ssl.key-store = classpath:keystore.jks
server.ssl.key-store-password = rootroot
But when I access https://localhost:8443 . The server returns no response and server is temporarily down.
Can you guide me what is going wrong?
Finally, I found the answer. I was using the keystore.jks generated from another machine instead of generating in server machine.
Now I solved the problem by using the keystore generated by keytool on server machine and everything went well.
Anyway, thank you for your answers.
Your information did not work for me, then I've did some researches and now it's working after I followed the below steps:
openssl pkcs12 -export -in <mycert.crt> -inkey <mykey.key> -out <mycert.p12> -name tomcat -CAfile <myca.ca> -caname root -chain
(I ran the above command to generate a pkcs12 in my digitalcert, which the only file that does not exists yet is the mycert.p12)
After that I've copied the mycert.p12 to src/main/resources
And finally this is my application.properties file configuration:
server.context-path=/cv2
server.port=8880
server.ssl.key-store=classpath:java_admin_checkverification_com.p12
And now everything is working like a charm!
PS: The configuration server.ssl.key-store was not working for me when I was at the version 1.2.4, because it was not finding the file in the classpath at all... Always throwing FileNotFoundException, so I updated to 1.3.5, with the above configurations and now everything is working.
I've had the same problem and adding the key-store-type fixed it:
server.ssl.key-store-type: JKS
"Tomcat requires the key store (and trust store if you’re using one) to be directly accessible on the filesystem, i.e. it cannot be read from within a jar file. This limitation doesn’t apply to Jetty and Undertow."
by default tomcat is used
If someone has same issue -
my settings are
server.port=8443
server.ssl.key-store=classpath:certs/localhost.keystore
server.ssl.key-store-password=somepass
server.ssl.key-password=somepass
I had a problem with my request - Ive been sending request to 127.0.0.1:8443, but my certificate had name localhost! I fixed request to localhost:8443 and all went right.
Reinstalling my cert with certbot fixed it for me. Just ran certbot and 1: Attempt to reinstall this existing certificate. I already had my config setup like the other answers. I'm not sure how this fixed it, but I figure I'd leave this answer here. I'm using Nginx.