1

So for example, Chrome browser (using F12 > security) will tell you what key-exchange, cipher, and protocol was used by a website's SSL certificate.

e.g.

protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_256_GCM).

Is there a way to tell if your own certificate is generated via what algorithm and key-exchange in linux? Using e.g. openssl?

I ask because I wasn't the IT guy from the hosting company who created the private key which was then used to send a CSR to our CA and gotten it signed.

I just want to know if he generated it correctly. I have the .csr, .pem files. I can ask, but I wanna know if there's a way to inspect.

Improve this question

1 Answer 1

Reset to default
4

... will tell you what key-exchange, cipher, and protocol was used by a website's SSL certificate.

This is wrong. Key exchange method, cipher and protocol are features of the TLS connection and not the certificate. In fact, these parameters are (mostly) independent of the certificate. They depend instead on the capabilities and configurations of the TLS stack in client and server.

The relevant features of the certificate are instead the type and the strength of the key (i.e. RSA-2048, ...), the issuing CA, and the signature algorithm used to sign the certificate (i.e. SHA-256, SHA-1, ...)

I have the .csr, .pem files. I can ask, but I wanna know if there's a way to inspect.

openssl req -text will show you (among other things) the information about the public key for the CSR, while openssl x509 -text will show you additionally the issuer which signed the certificate and the signature algorithm used.

You don't know from this if the admin used the proper openssl commands to generate the CSR. You don't even know if if he used openssl at all or instead some other tools. You can only see the result.

In the worst case the certificate were generated by using a weak random generator and are thus insecure, like in the case of the Debian random generator bug. But you will not be able to detect any broken random generator just from looking at the single certificate. And you also don't know how well your hosting provider protects the private key just from looking at the CSR or certificate.

Improve this answer
3
  • Good points. But I'm seeing an SSLv3 error in one of my databases using the certs. But both my DB & Java App are configured to be TLSv1.2 with SSLciphers TLSv1.2, so something must be wrong with certificates or a famous DB has wrong error messages. Otherwise why would it reject my certs considering the latest TLSv1.2 ciphers are being forced in both client & server.
    – Dexter
    Apr 30, 2017 at 17:18
  • 1
    @Dexter: OpenSSL based code often throws errors which have "ssl3" in the description simply because TLS and SSLv3 are very similar and thus the same functions are used for both. This does not mean that SSLv3 was used as the protocol. If you want to get to the real cause of these messages please make a new question with enough details.
    – Steffen Ullrich
    Apr 30, 2017 at 17:24
  • See that to me, is a bug that OpenSSL must correct. It is incredibly misleading. I did, here but no one seems to know... stackoverflow.com/questions/43689461/…
    – Dexter
    Apr 30, 2017 at 17:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .