You should be able to use OpenSSL for your purpose:
echo | openssl s_client -showcerts -servername gnupg.org -connect gnupg.org:443 2>/dev/null | openssl x509 -inform pem -noout -text
That command connects to the desired website and pipes the certificate in PEM format on to another openssl command that reads and parses the details.
(Note that "...
http://comments.gmane.org/gmane.comp.encryption.openssl.user/43587 suggests this one-liner:
openssl crl2pkcs7 -nocrl -certfile CHAINED.pem | openssl pkcs7 -print_certs -text -noout
It indeed worked for me, but I don't understand the details so can't say if there are any caveats.
Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).
Without automation: Longer lifespan is more convenient. LE may not be feasible if you, for whatever reason, cannot automate the certificate management
The signature of the root CA certificates do not matter at all, since there is no need to verify them. They are all self-signed.
If you trust a root CA certificate, there’s no need to verify its signature. If you don’t trust it, its signature is worthless for you.
Edit: there are some very relevant comments below. I don’t feel comfortable copying or ...
This is where Go looks for public root certificates:
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6
"/etc/ssl/ca-bundle.pem", // OpenSUSE
"/etc/pki/tls/cacert.pem", // OpenELEC
From a purely technical perspective:
The fact that the certificates are only valid for 3 months. Can be a nuisance to maintain depending on your change management procedures and infrastructure.
The purpose of Let's Encrypt certificates is limited. You can't use them for your email, code signing or timestamping.
Check with: openssl x509 -in cert.pem -...
One word - trust. The SSL certificate from a provider that your browser trusts means that they have at least done basic verification to say that you are who you say you are.
Otherwise I could make my own certificates for google.com or yourbank.com and pretend to be them.
Paid certificates do not provide any extra level of encryption over self signed (...
I'll answer this in two steps...
Do You Need an SSL Cert for Each Subdomain ?
Yes and No, it depends. Your standard SSL certificate will be for single domain, say www.domain.example. There are different types of certs you can aside from the standard single domain cert: wildcard and multi domain certs.
A wild card cert will be issued for something like *....
The order does matter, according to RFC 4346.
Here is a quote directly taken from the RFC:
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root ...
It can be achieved by various openssl calls.
PASSWORD is your current password
YourPKCSFile is the file you want to convert
NewPKCSWithoutPassphraseFile is the target file for the PKCS12 without passphrase
First, extract the certificate:
$ openssl pkcs12 -clcerts -nokeys -in "YourPKCSFile" \
-out certificate.crt -password pass:PASSWORD -passin pass:...
RFC 2818 in "3.1. Server Identity" states that
Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
So yes, it's the fact that it's two levels of subdomains that is the problem.
I believe that with respect to deciding where to purchase a wildcard SSL certificate, the only factors that matter are the first year's cost of an SSL certificate, and the pleasantness of the seller's website (i.e. user experience) for the purchase and setup of the certificate.
I am aware of the following:
Claims about warranties (e.g. $10K, $1.25M) are ...
You probably have SELinux in enforcing mode (the default for Fedora):
If this is the case, check the audit logs, you should find the access error:
ausearch -m avc -ts today | audit2allow
You also probably moved the filed instead of copying it, so the security context of the file might be wrong.
ls -lrtZ /etc/nginx/demo.*
and correct it if ...
At the end of the day, a root certificate is self-signed. It is never signed by another entity except itself. The root certificate gets its trust through out-of-band processes like submitting it to a browsers list of trusted publishers, or getting it accepted by Microsoft for insertion into the default list of Windows trusted publishers.
These certificates (...
The certificate name must match what the user entered in the browser, not the 'final' DNS record. If the user enters docs.tenantcompany.com then your SSL certificate has to cover that.
If docs.tenantcompany.com is a CNAME to foo.example.com, the certificate does not need to cover foo.example.com, just docs.tenantcompany.com.
Yes, it is possible. In the case of Windows, there is a feature called Cross-Certification or Qualified Subordination.
The idea is that you sign third party's issuing CA certificate in your environment. As the result remote SSL certificate is chained to your own root CA certificate. In order to protect yourself from possible rogue certificates, you ...
... Failed to tls handshake with 192.168.2.107 x509: cannot validate certificate for 192.168.2.107 because it doesn't contain any IP SANs
SSL needs identification of the peer, otherwise your connection might be against a man-in-the-middle which decrypts + sniffs/modifies the data and then forwards them encrypted again to the real target. Identification is ...
According to the SSL FAQ:
the validity (and thus level of trust) of a given certificate is determined by the corresponding validity of the higher-level certificate that signed it.
So while it is technically possible to make a certificate which lasts longer than its issuer, it makes no sense, as the chain becomes broken the moment an intermediate (or the ...
It really doesn't matter where you put them as long as you properly protect your private key file(s). The public certificate is public; no protection needed - server privileges or otherwise.
To expand on the answer, I do not use the default location /etc/ssl. It's easier for me to keep all mine in a separate area due to backups+other reasons.
For Apache ...
The simplest solution I've found is
Export to temporary pem file
openssl pkcs12 -in protected.p12 -nodes -out temp.pem
# -> Enter password
Convert pem back to p12
openssl pkcs12 -export -in temp.pem -out unprotected.p12
# -> Just press [return] twice for no password
Remove temporary certificate
Use openssl s_client piped to openssl x509:
$ openssl s_client -connect foo.example.com:443 < /dev/null | openssl x509 -text
(Add -servername foo.example.com to the s_client command if the server uses SNI.)
The redirection of stdin from /dev/null for the first invocation of openssl will prevent it from hanging waiting for input.
nmap -p 443 --script ssl-cert gnupg.org
The -p 443 specifies to scan port 443 only. All ports will be scanned if it is omitted, and the certificate details for any SSL service that is found will be displayed. The --script ssl-cert tells the Nmap scripting engine to run only the ssl-cert script. From the doc, this script "(r)etrieves a server's SSL ...