I have a comodo positive SSL certificate. put it on my server and started my server using this:
python manage.py runserver_plus --cert-file /my/cert --key-file /my/key 0.0.0.0:443
but it is not trusted in browsers yet. shows this:
I passed my files that have same name with my domain to runserver_plus. I think maybe i used wrong files.
now i want to know what is my problem?
What you have is not a certificate signed by a Comodo certificate authority (CA). It seems to be self-signed given that the issuer and subject appear to be the same.
Two solutions:
Accept this certificate in the web browser settings.
Or don't used a self-signed certificate. I doubt however that you can find a CA that will issue you a certificate for localhost.
Related
I am trying to setup a Kafka cluster with mTLS authentication using certificates signed by GCP's CAS (Certificate Authority Service). I have three Kafka nodes: a master and two workers. Each node has a PEM truststore containing the CA Root certificate from the authority on CAS and a PEM keystore containing a signed certificate from CAS and the private key. I followed this webpage for the setup.
This is the server.properties file for the master node. Other nodes have a similar config except the ssl.keystore.location property.
listeners=INTERNAL://:port,EXTERNAL://:port
advertised.listeners=INTERNAL://:port,EXTERNAL://:port
listener.security.protocol.map=INTERNAL:SSL,EXTERNAL:SSL
inter.broker.listener.name=INTERNAL
ssl.enabled.protocols=TLSv1.2
ssl.endpoint.identification.algorithm=
producer.ssl.endpoint.identification.algorithm=
consumer.ssl.endpoint.identification.algorithm=
ssl.client.auth=required
ssl.truststore.type=PEM
ssl.truststore.location=/path/ca.crt
ssl.keystore.type=PEM
ssl.key.password=<password>
ssl.keystore.location=/path/master.pem
The truststore is the ca.crt (Root CA certificate) file and the keystore has the private key and the signed certificate. There are no intermediate certificates, the certificates in the keystore are directly signed by the root certificate.
When I try to start the server on any nodes I am getting the following error. I am not sure why.
ERROR [KafkaServer id=0] Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)
org.apache.kafka.common.config.ConfigException: Invalid value javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. for configuration A client SSLEngine created with the provided settings can't connect to a server SSLEngine created with those settings.
P.S. I have already tried using the truststore and keystore in JKS and PKCS12 format. I keep getting the same error.
From what you shared, it doesn't seem that you've created valid keystores for the cert and CA.
ssl.truststore.location=/path/ca.crt
...
ssl.keystore.location=/path/master.pem
You're merely pointing to the original files. You need to create two valid java keystores with a JDK's keytool tool and import the files into each one. Depending on your certificate format you might need to convert them with openssl.
See https://stackoverflow.com/a/11954816/50114 for an example.
You mentioned earlier that you got the same error with JKS keystore and truststore. From the error message, it sounds like the keystore may not contain the whole chain. Can you first try with a JKS truststore containing the root cert and a JKS keystore containing the private key and the whole certificate chain (i.e. including root cert)?
If that run gives the same error, you could enable "javax.net.debug=ssl". If using Kafka scripts to start the broker, you can first export KAFKA_OPTS=javax.net.debug=ssl. Broker performs extra validation by attempting handshake using the provided keystore and truststore for the inter-broker listener. It looks like that validation is failing in your case. The extra debug may help to understand why.
Once you have the broker running with JKS, you can switch to PEM if required.
What does your keystore PEM file look like?
Does it have clear separate sections (with BEGIN and END)? See https://docs.progress.com/en-US/bundle/datadirect-hybrid-data-pipeline-installation-46/page/PEM-file-format.html
Can you try adding the Root CA in the PEM file too, after the signed certificate?
If I make a request to my Daphne/Django server in Postman or the Android app we're developing, Daphne serves the certificate, but it's rejected. If I first make a simple get request to https://letsencrypt.org/ and then make a request to my server, the certificate is accepted.
How can I make sure a client will trust my certificate, even if it's the first time this client is seeing a certificate issued by this CA?
Everything bellow can serve as a history of how I studied the problem.
Original title: SSL Certificate works in browser but can't be verified by Postman
I have an AWS EC2 instance running Ubuntu 18.04, with python 3, Django, a bunch of project dependencies, Daphne running with ASGI, with a certificate by Let's Encrypt. Daphne is using port 8000 for HTTP and por 4430 for HTTPS, iptables is configured to redirect requests from port 80 to 8000 and from port 443 to 4430. Django is configured to enforce secure connections with SECURE_SSL_REDIRECT=True in the settings.py file.
There's a "Site in Construction" temporary page being served, and it's properly accessible from every browser and every device I tested so far. If I explicitly type http, I get redirected to https and the certificate is accepted. Every browser I tested (Firefox, Brave, Chrome, Chrome for Android) says cert is good.
Curl outputs the HTML content returned from the server. I don't know if it accepts the certificate or ignores it.
The Problem
Postman, however, says "Error: unable to verify the first certificate". Only works when I disable "SSL certificate verification", which doesn't answer my question: why Postman is unable to verify my Let's Encrypt certificate?
I'm building an API that runs on the same server, using the same domain, and it's meant to be consumed by a mobile app. Currently, the Android app is throwing a "TypeError: Network request failed", which I suspect could be caused by the same thing Postman is complaining about.
When I spin the server locally and configure 1) the app to use http://localhost:8000 and 2) the server not to enforce SSL, it works in browsers, Postman and in the Android app.
I've being looking for answers in many places for days, so any clue will be very welcome.
EDIT
Interesting clue:
If I make a request to my Daphne/Django server, it servers the certificate, which is rejected. But if I first make a request to https://letsencrypt.org/ and then make a request to my server, it works!
This pattern holds true in both Postman and our Android app.
It also happens when I first make a request to https://alloy.city (instead of letsencrypt.org), which is served by a Node.js app, and uses a certificate also issued by the Let's Encrypt CA.
So maybe the question should be: how to configure my server to politely invite clients to add the CA that issued my certificate if they hadn't done it yet?.
Apparently, that's what my Node.js server does.
Yes, in settings, tap ssl verification off
File > Settings > General > SSL Certificate Verification > off
The title of the question is a mouthful, but I am trying to configure a Go Daddy SSL cert which I purchased for my domain on AWS. I purchased the domain myapp.com (not the real name) from AWS, and then I configured myapp.myapp.com as a record set in Route 53 to point to an EC2 instance, which in turn is running the actual Tomcat server which I expect users would be hitting. In other words, this is the site used to hit the app/website, and I have confirmed that it works and is reachable.
I purchased an SSL cert from Go Daddy for myapp.myapp.com. I followed the instructions to import the root, intermediate, and issued certificates (3 in total) into my Java keystore. Then, I configured my Tomcat server.xml to use this keystore. I am not certain that I did this correctly, or in the correct order, if that matters. In any case, when I try to hit the address
https://myapp.myapp.com:8443/
I get the following error on Chrome:
Your connection is not private
NET::ERR_CERT_AUTHORITY_INVALID
Can anyone shed some light on what I might be doing wrong here? Go Daddy's customer support, while free, does not offer this level of tech support. I could go with AWS, but they tend to charge enterprise rates.
An ideal answer would include, at least as an outline, the following steps:
How to import the Go Daddy certs into my Java keystone
How to configure Tomcat server.xml properly to use the keystore
Sanity checks along the way, which someone else with a similar problem would be able to use
Here are the three certs which Go Daddy returned to me:
c4c170b79c58acc3.crt (root?)
gd_bundle-g2-g1.crt (intermediate?)
gdig2.crt.pem (primary/issued?)
I am not sure which of these certs are root, intermediate, and issued, but this SO question would label them as I have above.
To do this for a spring boot app do the following:
sudo openssl pkcs12 -export -out cs.pkcs12 -inkey /path/to/domain.key -in /path/to/domain.cer -certfile /path/to/domain.ca-bundle -name server -passout somestorepass
sudo keytool -v -importkeystore -srckeystore cs.pkcs12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS -srcstorepass somestorepass -deststorepass somestorepass
in application.properties
server.ssl.enabled=true
server.ssl.key-alias=server
server.ssl.key-password=somestorepass
server.ssl.key-store-type=JKS
If you have tomcat, the first two commands stay the same, you just need to configure tomcat to to use the correct alias and the correct key store password.
Have a look at the Connector configuration for tomcat to configure the alias, keystore password, keystore etc.
Edit:
Would recommend that you delete the intermediate files (not the JKS) once done.
I had never installed SSL onto a Windows Server before, now I ran into a problem.
I had a website hosted by Smarter ASP, and I got a SSL certificate from them. Then I moved the website into Azure as a App Service, without creating a virtual server myself. I imported the pfx file into Azure, and it worked.
Now I want to move the website into AWS.
I created a Windows Server EC2 instance in AWS. I did all the A Record and CNames changes. Now when I request "www.teacherspet.net.au", the home page is returned without any problem.
I then did the following to import the SSL certificate into the AWS EC2 server:
On "Server Certificates", I imported the pfx file using "WebHosting" as the certificate store;
I added a HTTPS binding on the site, with ip address being "*" and host name being empty;
I checked the "Require SSL" checkbox on "SSL Settings".
I have also added the same pfx file into intermediate certificate:
However, when I requested "https://www.teacherspet.net.au", I got
This site can’t be reached
www.teacherspet.net.au took too long to respond.
Why? I can't figure out what went wrong. Please help!
I am terribly sorry for the silly mistake - when I created the Network ACL inbound rule, instead of selecting "HTTPS (443)", I accidentally selected "HTTPS* (8443)". Once I corrected it, everything works. Thank you disflux for your help!
I need to be able to hit a web service using SoapUI to inspect the request and response. I was previously provided with a certificate in the form of a .PFX file, along with the keystore password, which I could import into SoapUI and successfully hit the service.
The certificate I was provided recently expired, and my company has now deployed a new certificate via SCCM to my machine. I have the certificate installed in both Local Machine and Current User.
My question is:
Is there a way to use an installed certificate (meaning I can't export it first) to complete the SSL/TLS handshake when making a request via SoapUI?
Everything I've been able to find on the web has referenced exporting the certificate and setting the SSL settings in SoapUI (like I did before). Unfortunately, I do not have required authority to export the certificate to a .PFX file with a keystore password...
I assume there has to be a configuration setting of some sort in SoapUI that will let me hit the service with my installed certificate, but I can't find it for the life of me. Any help is greatly appreciated!
Even confirmation that it's impossible is appreciated; just not as much as I would appreciate a solution ;)
Thanks in advance!