The OpenSSL command-line utility can be used to inspect certificates (and private keys, and many other things). To see everything in the certificate, you can do:
openssl x509 -in CERT.pem -noout -text
To get the SHA256 fingerprint, you'd do:
openssl x509 -in CERT.pem -noout -sha256 -fingerprint
The solution I finally came to was to pipe it through sed.
openssl pkcs12 -in <filename.pfx> -nocerts -nodes | sed -ne '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' > <clientcert.key>
openssl pkcs12 -in <filename.pfx> -clcerts -nokeys | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <clientcert.cer>
openssl pkcs12 -in &...
You have two ways of creating certificates in the past. Either faking the time (1)(2), or defining the time interval when signing the certificate (3).
1) Firstly, about faking the time: to make one program think it is in a different date from the system, have a look at libfaketime and faketime
To install it in Debian:
sudo apt-get install faketime
Yes, I'm pretty sure you would need to reload Nginx in order for the renewed certificates to display the correct expiration date, but a simple cache-clearing and browse should allow you to view this.
Or if you prefer cli, you could always use the old trusty OpenSSL command:
echo | openssl s_client -connect your.domain.com:443 | openssl x509 -noout -dates
From a web site, you can do:
openssl s_client -showcerts -verify 5 -connect stackexchange.com:443 < /dev/null
That will show the certificate chain and all the certificates the server presented.
Now, if I save those two certificates to files, I can use openssl verify:
$ openssl verify -show_chain -untrusted dc-sha2.crt se.crt
That means certificate on the server has been expired or it is invalid.
As for the workaround, use the LDAPTLS_REQCERT variable to ignore the certificate, e.g.:
LDAPTLS_REQCERT=never ldapsearch -D "cn=drupal-test,ou=Services,dc=example,dc=com" -w my_pass -h ldap.example.com -b "ou=People,dc=example,dc=com" -s sub -x -ZZ "(uid=admin)"
Otherwise you can ...
On receiving SIGHUP nginx will reload updated configuration, verify it while opening log files and reading SSL certificates, then gracefully shut down worker processes relying on previous configuration.
If it happens that nginx can't read some SSL certificates, I'll continue to run using older configuration. Otherwise put, it'll continue to function and ...
Your command would now expect a http request such as GET index.php for example. Use this instead:
if true | openssl s_client -connect www.google.com:443 2>/dev/null | \
openssl x509 -noout -checkend 0; then
echo "Certificate is not expired"
echo "Certificate is expired"
true: will just give no input followed by eof, so that openssl exits ...
What you need is a chain certificate. You can create one like this:
cat /etc/ssl/server.pem /etc/ssl/cacert.pem > /etc/ssl/chain.pem
and then use the chain as the server certificate
ssl_cert = </etc/ssl/chain.pem
ssl_key = </etc/ssl/server.key
Now when you connect with openssl s_client, you should get no errors (provided everything else is set ...
I am posting an answer to my own question because I solved the problem and I did not find a valid solution elsewhere. There is no /etc/ssl/certs/ca-certificate-crt file. So a link needs to be provided to the proper cert.
$ ln -s /etc/ca-certificates/extracted/ca-bundle.trust.crt /etc/ssl/certs/ca-certificates.crt
Now I can curl and git clone through https.
Those are NSS built-in certificates. They are provided through a shared library: /usr/lib/libnssckbi.so (path may be different on your system). That's where Chrome gets them from.
You could list them with certutil like this:
Make a link to the library in ~/.pki/nssdb:
ln -s /usr/lib/libnssckbi.so ~/.pki/nssdb
certutil -L -d sql:$HOME/.pki/nssdb/...
No, it is not possible to generate the private.key file from the certificate.crt file. You will need to generate a new key and a new certificate, if the below does not apply to you.
You may ask your certificate provider if they're willing to re-generate your certificate, a few companies offer the possibility.
You can configure certain parameters for the HTTPS transport in /etc/apt/apt.conf.d/ — see man apt.conf (section "THE ACQUIRE GROUP", subsection "https") for details.
There is also a helpful example over at the trusted-apt project.
For example, you can disable certificate checking completely:
// Do not verify peer certificate
The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.
Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.
If your admin refuses/can't do this for some reason, your ...
It get's them from the underlying operating system. You can read about it here:
Root Certificate Policy
excerpt from above link
Google Chrome attempts to use the root certificate store of the
underlying operating system to determine whether an SSL certificate
presented by a site is indeed trustworthy, with a few exceptions.
That page goes on to ...
Use the openssl command to get output from /etc/ssl/certs/ca-bundle.crt
Anyway, I tried the following, mostly copied from https://unix.stackexchange.com/a/97249/48498, and it seemed to work if I changed the filename to account for CentOS 6:
If you don't want to have to bother with the --insecure flag or its analogues on cURL, wget, Git, etc, you can add a ...
You could simply write it:
openssl s_client -showcerts -connect encrypted.google.com:443 < /dev/null \
2> /dev/null | openssl x509 -noout -enddate
Other options than -enddate can be used to retrieve other fields. -text outputs most of the information.
See also keytool from java:
keytool -printcert -sslserver encrypted.google.com:443
It will ...
I believe you're looking for the update-ca-certificates command. That should not require any user input.
However, you're installing the certificate in the wrong place; you want to put it in /usr/local/share/ca-certificates/; that is the directory for locally-added certificates and any added there are automatically trusted.
If you really want to put it in /...
It turns out that the openssl s_client on Ubuntu 10.04 still queries a default location for system installed certificates, even if -CApath and -CAfile are specified:
8466 open("/usr/lib/ssl/certs/4e18c148.0", O_RDONLY) = 4
$ ls -l /usr/lib/ssl/certs/4e18c148.0
lrwxrwxrwx 1 root root 30 2014-04-11 21:50 /usr/lib/ssl/certs/4e18c148....
Just to make things difficult, Linux has more than one library for working with certificates.
If you're using Mozilla's NSS, you can Actively Distrust (their terminology) a certificate using certutil's -t trustargs option:
$ certutil -d <path to directory containing database> -M -t p -n "Blue Coat Public Services Intermediate CA"
For Firefox, <...
If you are using Debian or Ubuntu operating system please install the package
$ sudo apt-get install ca-certificates
If you don't care about checking the validity the certificate use --no-check-cetificate:
$ wget --no-check-certificate https://download/url
NOTE: Second option not recommended because of possibility to man-in-the-middle attack.
I'm almost surprised to find that the obvious thing works: whereas openssl takes as an argument the number of days for which the certificate should be valid, just supply a negative number!
openssl req -x509 -newkey rsa:4096 \
-keyout key.pem -out cert.pem -days -365
Note that this actually results in something very strange: a certificate whose expiry ...
Warning: Before you dive into the minefield of running your own Certification Authority, you may need to study the security implications!
But if you must, read on for a quick and dirty CA that will give you https://localhost/ without a warning message...
Create the following text file:
# OpenSSL configuration for Root CA
[ req ]
prompt = no