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 ?
Related
I am hosting my IdentityServer, Web API and MVC client apps all with IIS server, under HTTPS. When I run the my MVC client I get the following error back (note - 6009 is the port of my MVC client and 6005 is the port of my IdentityServer):
I am using IIS Express Development Certificate for all projects when I configure them in IIS:
and I copied the certificate from the personal store to the trusted root as the following:
and here is the details of the cert:
what else am I missing here?
You can refer to the official link,and try the commands in it.
dotnet dev-certs https --clean
dotnet dev-certs https --trust
For me, neither dotnet dev-certs https --clean/trust nor manually cleaning the Windows certificate stores worked out.
Since I was using Docker and Kestrel (instead of ISS), for some reason, it was using outdated certificates located under: C:\Users\<user>\AppData\Roaming\ASP.NET\Https\<project-name>.pfx The dotnet dev-certs https --clean command did not clean up the certificates in this directory.
After cleaning the certificates in this directory, everything worked again. I'm aware that your problem is already resolved, but since this is a common issue I figured I would also post my solution here.
Related issue about why the clean command does not clean these certs can be found here: https://github.com/dotnet/aspnetcore/issues/15357
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.
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!
On my local dev machine (osx), I'm using jboss to server web services on 8443. When I hit the urls directly I get the json responses I'm looking for. The architecture we have at work includes a middle layer (apache/php) that does authentication and routing. If things authenticate then it forwards the request to the backend.
When I was working with apache on port 80 and jboss on 8081 (using http). Everything worked fine for me. Now that I'm trying to use 8443, things aren't working.
I recently changed the backend to server through https (8443) instead of http (8081). I can hit the requests on https 8443 directly and get the json response. When I hit apache and it authenticates then tries to redirect to the https 8443 I get the following message from chrome's inspector: "SSL: can't load CA certificate file /etc/pki/tls/certs/ca-bundle.crt".
My vhost is setup to catch *:80 requests. I think I might need to setup vhosts to accept 443 requests or install ca-certificates like talked about in How do I deal with certificates using cURL while trying to access an HTTPS url? . I'm looking to see if anyone knows what the proper direction should be.
When I look on the file system, the file /etc/pki/tls/certs/ca-bundle.crt doesn't exist. When I make the request to the middle layer, I see the request hit /var/log/apache2/access_log and nothing comes up in /var/log/apache2/error_log.
What is needed to resolve this issue? Is it a configuration of vhosts to catch request to 443? Is it to install ca-cert stuff like in the link? A combination of both? Or something else? Please provide enough info on how to solve it, or provide links that provide enough info.
I solved my issue and am doing a post for documentation purposes, in case anyone else has similar issues. There was a couple of issues I had to resolve to fix this.
PHP Install
My /etc/apache2/httpd.conf referenced my default osx php install instead of my home brew install of php. Solution was to edit the httpd.conf and point it to the right install.
#LoadModule php5_module /usr/local/opt/php53/libexec/apache2/libphp5.so
LoadModule php5_module /usr/local/Cellar/php53/5.3.29_4/libexec/apache2/libphp5.so
You can create a similar setup of php using home brew by the following commands:
brew install homebrew/php/php53
brew install homebrew/php/php53-igbinary --build-from-source
brew install homebrew/php/php53-intl
brew install homebrew/php/php53-mcrypt
brew install homebrew/php/php53-memcached
brew install homebrew/php/php53-mongo
brew install homebrew/php/php53-xdebug
Create the CA Cert Bundle File
The system is looking for /etc/pki/tls/certs/ca-bundle.cert which is a standard path on linux, but not on osx. We get around this by generating the file.
I generated the .keystore file using keytool and used jboss for my alias. In order to build the ca bundle file, we need it to be in the pem format, so we need to add the -rfc to our export statement. Below are the commands:
cd /usr/local/jboss-eap-6.4/standalone/configuration
keytool -export -alias jboss -file local-sbx.dev.yourcompany.com.crt -keystore .keystore -rfc
After you have the file, you can cat it out and verify that the file has the BEGIN CERTIFICATE and END CERTIFICATE stuff in it. If so, its in the right format.
Lastly, create the directory structure, move the cert to act like the bundle (which is just a bunch of certs appended to each other) and then restart apache:
mkdir -p /etc/pki/tls/certs/
sudo cp local-sbx.dev.yourcompany.com.crt /etc/pki/tls/certs/ca-bundle.crt
sudo apachectl restart
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.