I am creating SSL certificate with certbot with this command:
sudo certbot certonly --manual --preferred-challenges=dns --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.foo.bar --email foo#bar.com
in nginx configuration I am giving fullchain.pem and priveKey.pem for SSL handshake. everything is ok with no error. but the problem is when I am trying to reach https://jjj.foo.bar it says the certificate is not trusted. but I can accept and proceed to my request. so I checked my site with https://www.sslshopper.com/ for checking where is the issue . all of the tests are passed but common names are mismatched . why?
Related
Thanks in advance for your time and response.
I have generated a certificate using certbot.
certbot -d *.mycompany.com --manual --preferred-challenges dns certonly
I create the TXT record in my (Amazon Rt53) dns and have created the private and public keys.
I then convert it to .pfx
openssl pkcs12 -inkey privkey.pem -in fullchain.pem -export -out mycompany.pfx
I use the resulting mycompany.pfx in RD gateway and elsewhere in multiple servers (since I have a *.mycompany.com).
Obviously letencrypt expires in 90 days. So I renew the certificate by issuing the same command
certbot -d *.mycompany.com --manual --preferred-challenges dns certonly
I get the new keys.
I now have to go to the RD gateway server and re-import the new .pfx certificate.
I have to do this for each server where I have used the certificate.
Is this the way this is supposed to work ? Is there an automated step that I am missing whereby
I renew and
all the servers where I have used the certificate renews
automatically?
Automatic renewal of letsencrypt certificates or certbot certificates.
Certbot can be configured to renew your certificates automatically before they expire.
You can set cron job to renew certificates automatically.
Go to your server and run sudo crontab -e. It will open window add following command.
0 0 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && /home/centos/certbot/certbot-auto renew >> /var/log/auto-renewal-cron 2>&1
You can get cron command by selecting system & software based on your OS like below screenshot: https://certbot.eff.org/lets-encrypt/osx-apache.html
Is there anyoune out there who got a running arangoDB database working with a letsencrypt certificate? I just can't find out to geht this running.
ArangoDB is running on a digitalOcean droplet and I could get it running togehter with a self-signed certificate following this tutorial. So arangoDB is sucessfully running on port: 8530
Now my approach was replacing the self-signed certificate with a letsencrypt cert.
So I added a subdomain in DigitalOcean to the droplet. e.g.: db.example.com an then generated the cert-files:
sudo -H ./letsencrypt-auto certonly --standalone -d db.example.com
You will end up with 4 files: cert.pem chain.pem fullchain.pem privkey.pem
As I understood, these files are:
Private Key --------> privkey.pem
Public Key ---------> cert.pem
Certificate Chain --> chain.pem
As described in the tutorial I mentioned, you nee the certificate and the key in one file. So i did
cat chain.pem privkey.pem | sudo tee server.pem
to have a file containing the certificate and the private key.
Then I modified the file /etc/arangodb3/arangod.conf to let arango know where the keyfile is and modified the ssl section:
[ssl]
keyfile = /etc/letsencrypt/live/db.example.com/server.pem
But after restarting arango, the server is not available. When trying to connect the browser to: https://db.example.com:8530. Firewall settings for the droplet should all be ok, because I could access this address with the self-signed cetificate before.
I then tried to modify the endpoint in /etc/arangodb3/arangod.conf from
endpoint = ssl://0.0.0.0:8530
to
endpoint = ssl://db.example.com:8530
and also
tcp://db.example.com:8530
None of it was working. Has somebody out there an idea what I am doing wrong?
Please use the ip of the interface you want to use when specifying the endpoint e.g. endpoint = ssl://42.23.13.37:8530 (ip address should list your interfaces along with addresses in use). Then it could help to use the fullchain.pem to create the server.prm (cat fullchain.pem privkey.pem > server.pem). Make sure the resulting server.pem is accessible and readable by the arangodb user. If the server is still not starting correctly please provide logs of the server. To access the logs use systemctl -fu arangodb3.service or follow the logs with tail -f <logfile> if you use some custom location for logging.
I have just tested a setup with letsencrypt certificates and it was working after ensuring all above points.
Heroku gives simple instructions for updating your certificates for SSL:
$ heroku certs:update server.crt server.key
However, there is no indication that any verification is done before deploying. As this is production, I want to be sure that the two files I'm giving them will not cause any security snafus.
I have my foo_com.crt (which was signed by DigiCert), server.key, and DigitCertCA.crt.
I've found that I can use security verify-cert -c certificate.pem to verify my certificate (on OS X). My certificate doesn't verify though:
$ security verify-cert -c foo_com.crt
Cert Verify Result: CSSMERR_TP_NOT_TRUSTED
Which leads me to believe that my intermediary may not be trusted but:
$ security verify-cert -c DigiCertCA.crt
...certificate verification successful.
Specifying a purpose of SSL succeeds too
$ security verify-cert -p ssl -c foo_com.crt
...certificate verification successful.
I tried on a Linux box as well with similar mixed results.
$ openssl verify foo_com.crt
C = __, ST = ___, L = ___, O = "Foo Inc", CN = foo.com
error 20 at 0 depth lookup: unable to get local issuer certificate
error foo_com.crt: verification failed
$ openssl verify -CAfile DigiCertCA.crt foo_com.crt
foo_com.crt: OK
$ openssl verify -purpose sslserver -CApath /etc/ssl/certs foo_com.crt
C = __, ST = ___, L = ___, O = "Foo Inc", CN = foo.com
error 20 at 0 depth lookup: unable to get local issuer certificate
error foo_com.crt: verification failed
How can I be sure that when I update my certificates in Heroku, that everything will work smoothly?
Related: Renewing SSL certificate on Heroku
A suggestion from a colleague to run nginx led me to a confident way to know that everything would deploy smoothly.
I configured nginx with
server {
listen 443 http2 ssl;
listen [::]:443 http2 ssl;
server_name server_IP_address;
ssl_certificate /Users/traff/cert/gd.crt;
ssl_certificate_key /Users/traff/cert/server.key;
server_name localhost;
...
}
Once I had my nginx server set up I ran openssl s_client -connect localhost:443 -CApath /etc/ssl/certs. Then, after setting up foo.com in my hosts to point to my nginx server. I used curl https://foo.com.
Using the concatenation of foo_com.crt and DigiCertCA.crt (in that order) and server.key, upload was successful.
Furthermore, though Heroku's documentation does not state it, the update step does verify that SSL will serve properly
$ heroku certs:update foo_com_DigiCertCA_cat.crt server.key -a my-app
Resolving trust chain... done
_ Potentially Destructive Action
_ This command will change the certificate of endpoint ____
_ (_______.herokussl.com) from _ my-app.
_ To proceed, type my-app or re-run this command with
_ --confirm my-app
> my-app
Updating SSL certificate _____ (____.herokussl.com) for _ my-app... done
Updated certificate details:
Common Name(s): foo.com
Expires At: DateTime
Issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
Starts At: DigiCert
Subject: blah blah blah
SSL certificate is verified by a root authority.
I tried following the guide shown by mosquitto but once I launch the mosquitto
mosquitto -c mosquitto.conf
which defines port, location of ca.crt, server.crt, server.key
then I followed similar step using the same CA file, to sign the client key and certificate.
Then launched client
mosquitto_pub -p [port] -h localhost --cafile [ca.crt filepath] -t "hello" -m "hello world"
when I do it like this without key and certificate I get
Error: Success
but when I do it with key and certificate
mosquitto_pub -p [port] -h localhost --cafile [ca.crt filepath] --cert [client.crt path] --key [client1.key path] t "hello" -m "hello world"
I get
Error:Success
On the server side I See the following errors
... routines:SSL3_READ_BYTES: sslv3 alert certificate unknown
... routines:SSL3_READ_BYTES: ssl handshake failure
I ran openssl commands to verify CA approves of both generated certificates, and it did.
It turns out, when entering the detail of the certificate, i mistake the common name section's purpose. After I set it to the ip address of the server, it all worked well
I was getting the same error. I tried to subscribe like this:
mosquitto_sub -h ip_address -p 8883 -t topic --cafile /etc/mosquitto/ca_certificates/ca.crt -d.
Replace ip_addres with your ip address that you wrote when you created certificate. In your question, you wrote localhost. If you replace it with ip address it will be work.
I'm developing a program where I have a virtual development server that runs with a self signed certificate. My program uses curl to connect to the server and pull information, but needs to do so with SSL. When I try to connect I get the error "SSL certificate problem, verify that the CA cert is OK." When running firefox I can add the certificate to just firefox, but that doesn't help me with curl. How do I add the certificate for curl to recognize?
curl 7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Ubuntu 10.04 Lucid Lynx 64bit
This is one way that worked for me:
First, get the CA cert from the development domain and save it to a file called 'logfile'. (Assumes port 443 for SSL)
openssl s_client -connect xxxxx.com:443 |tee logfile
Then, use the --cacert curl option to use the saved certificate file.
curl --cacert logfile **THE REST OF YOUR CURL COMMAND**
Source:
http://curl.haxx.se/docs/sslcerts.html
I'd copy the certificate to /usr/local/share/ca-certificates/.
Let me quote the man page for update-ca-certificates:
Furthermore all certificates with a .crt extension found below /usr/local/share/ca-certificates are also included as implicitly trusted.
Add your rootCA.pem in /usr/share/ca-certificates directory.
After that update your certificates with: update-ca-certificates --fresh command.
I just did that, and works fine.
First, in your Linux, you should add your CERTIFICATE.cert to /usr/local/share/ca-certificates/.
After that by adding --cacert CERTIFICATE.cert to your command, curl will automatically use this certificate in that request.
Exp:
curl --cacert CERTIFICATE.cert GET "URL".
Obviously, you can edit the request to have your desired request.