How do I find out if a certificate is self-signed or authorized by CA? Somewhere I read that self-signed subject and issuer will be same, is it correct?

  • 4
    Watch out, a certificate which isn't self signed isn't automatically authorized by a CA in your trust list -- it just means some other certificate is higher in the chain. And conversely, root certificates (those in your trust store) are most times self signed.
    – user10008
    Commented Jul 5, 2015 at 16:58
  • Use: keytool -printcert -file <PEM format cert file> Both subject and issuer should be the same.
    – Dave
    Commented Sep 8, 2016 at 13:37

5 Answers 5


Yes it is true. When certificate is self-signed, then issuer and subject field contains the same value. Also, there will be only this one certificate in the certificate path.

  • 8
    Reading RFC 3280 it seems this is the condition for self-issued, a distinct concept from self-signed: "A certificate is self-issued if the DNs that appear in the subject and issuer fields are identical and are not empty. In general, the issuer and subject of the certificates that make up a path are different for each certificate. However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints." Commented Jun 19, 2017 at 9:49

Self-signed certificate will have identical subject and issuer fields, but a) this is not guaranteed, and b) the inverse is not true. Just because the fields have the same value that does not mean the certificate is self-signed.

Here are the outputs from one of our internal root (root-ca.crt) and intermediate certificates (ca.crt):

$ openssl x509 -subject -issuer -noout -in root-ca.crt 
subject= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA
issuer= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA

$ openssl x509 -subject -issuer -noout -in ca.crt 
subject= /CN=classmarkets CA/C=DE/L=Berlin/O=classmarkets GmbH/ST=Berlin
issuer= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA

You can see that the fields are the same for both certificates, even though ca.crt has been signed by root-ca.crt:

$ openssl x509 -noout -text -in ca.crt | grep -A1 'Key Identifier'
        X509v3 Authority Key Identifier: 
        X509v3 Subject Key Identifier: 

$ openssl x509 -noout -text -in root-ca.crt | grep -A1 'Key Identifier'
        X509v3 Subject Key Identifier: 

Note the absence of the Authority Key Identifier in root-ca.crt.

RFC3280 states in section (emphasis mine):

The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building.

So it seems to me that the Authority and Subject Key Identifiers are a much better indicator for self-signed certs than the Issuer and Subject fields. For a self-signed certificate the Authority Key Identifier will either be absent or have the same value as the Subject Key Identifier.

  • Are Subject, Subject Key, and Subject Key Identifier all the same field? Commented Apr 2, 2021 at 23:09
  • @pacoverflow, no the subject and subject key identifier are distinct fields. See the output above.
    – Peter
    Commented Apr 3, 2021 at 10:55
  • How do I do these checks for certificate with .der extension. Trying the same commands gives me "unable to load certificate" and says "Expecting: Trusted Certificate" ? Commented Jul 11, 2023 at 10:23
  • 1
    @node_analyser, from memory: -inform der
    – Peter
    Commented Jul 11, 2023 at 11:15

@Vilican answer is technically correct and should do the job most of the time. But I wanted to find out if a certificate I was examining (not some particular web site) was used as a self-signed certificate or was a CA cert.

What I found out is that valid Root CA certificates have same issuer and subject. Also Extensions -> Certificate Basic Constraints indicates this is a CA as well number of allowed intermediate CAs to be signed by this one.

While self-signed certs used to secure a web site usually are not marked as CAs as well have a DNS name as CN in Subject. And/or have a list of allowed DNS names/IPaddresses under Extensions -> Certificate subject alt name.


I suppose it's not correctly to check only match of subject and issuer of a certificate. There are plenty of options where different certificates with different start/end date or other metadata to have same subject and issuer. I'm using following method to check certificate is self-signed:

openssl verify -CAfile /cert/to/check.pem -CApath /cert/to/check.pem /cert/to/check.pem

Then if this check failed it's possible to check if certificate is signed with another certificate:

openssl verify -CAfile /cert/of/issuer.pem -CApath /cert/of/issuer.pem /cert/to/check.pem

Specifying same certificate as CAfile and CApath prevents successful verification against default trusted certificates of OpenSSL.

  • I have mutated several bytes in a self-signed certificate's signature field and this command still gives me OK. (I'm not sure whether the self-signature MUST be valid, just pointing out this command doesn't seem to verify it) Commented Jun 19, 2017 at 9:39
  • 1
    @Beni: OpenSSL never verified the signature on a selfsigned/root cert, until it became optional (-check_ss_sig) but not default in 1.1.0 -- which was actually out in late 2016, but not quickly adopted. And to be clear, modifying anything in the labelled, human-readable part of a PEM file has no effect; you must modify the portion of the base64 blob that decodes to the signature. Commented Sep 9, 2018 at 4:22

Sometimes not self-signed certificate have same subject and issuer.

openssl s_client - can check certificate

Test real certificate

DOMAIN="google.com"; PORT="443"
echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:$PORT" > /dev/null
depth=3 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = *.google.com
verify return:1

Test self-signed certificate

DOMAIN="lan.local"; PORT="443"
echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:$PORT" > /dev/null
depth=1 C = US, O = xxx LLC, OU = rootCA, CN = Local xxx LLC Root CA, emailAddress = [email protected]
verify error:num=19:self signed certificate in certificate chain

I have normal certificate


openssl s_client output

depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA
verify return:1
depth=0 C = US, ST = North Carolina, O = xxx, CN = xxx.xxx
verify return:1
  • Please don't downvote without explaining what's wrong! Commented Aug 5, 2023 at 12:00
  • This appears to be a duplicate answer, which contains less useful information than already existing answers apparently, because mainly just plain output is shown.. Commented Aug 5, 2023 at 12:02
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Aug 5, 2023 at 12:02

You must log in to answer this question.

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