SSL: unable to obtain common name from peer certificate

12,979

Solution 1

Try CURLOPT_SSL_VERIFYHOST=0 or curl -k

Solution 2

Without knowing the data used to generate the CSR, it looks like the last component of your DN does not contain a CN attribute with the target host name. Typically SSL library clients will only check the first component for the CN attribute equal to the target host name. I would reverse the DN order and add a CN attribute with the host name.

If you provide more details on how you generated the CSR I would be happy to help you figure out how to fix it.

Solution 3

The subject details from server cert from peer is :

subject: C=CN; ST=Beijing; L=Beijing; O=XiaoMi

The Issuer subject details is :

C=CN, ST=Beijing, L=Beijing, O=OKK, OU=Test, CN=MyComp Validity

Clearly the two are different (in case there was supposed to be any link attempted), since that is what I understood from the question.

In any case as seen in the curl error, the common-name attribute is missing. This could likely be due to that the certificate that was presented never contained it.

Suggest you try opening the certificate from a browser and verify.

Share:
12,979
Freeman Zhang
Author by

Freeman Zhang

Updated on June 06, 2022

Comments

  • Freeman Zhang
    Freeman Zhang almost 2 years

    Sorry, My mistake, there's two things must be highlighted:

    The CA cert Common Name must not same to the server/client side cert
    The server/client side cert's common name must be same
    

    I'm trying to using self-signed certificate for HTTPS Client side certificate. But, there's a problem " SSL: unable to obtain common name from peer certificate "

    As you can see, the server side cert contains Common Name, why this problem occurs?

    Here's curl output:

    • About to connect() to 127.0.0.1 port 443 (#0)
    • Trying 127.0.0.1... connected Enter PEM pass phrase:
    • successfully set certificate verify locations:
    • CAfile: /home/freeman/dev/git/ca_tools/ca_tools/ssl/CA/secure_ca.crt CApath: /etc/ssl/certs
    • SSLv3, TLS handshake, Client hello (1):
    • SSLv3, TLS handshake, Server hello (2):
    • SSLv3, TLS handshake, CERT (11):
    • SSLv3, TLS handshake, Server key exchange (12):
    • SSLv3, TLS handshake, Request CERT (13):
    • SSLv3, TLS handshake, Server finished (14):
    • SSLv3, TLS handshake, CERT (11):
    • SSLv3, TLS handshake, Client key exchange (16):
    • SSLv3, TLS handshake, CERT verify (15):
    • SSLv3, TLS change cipher, Client hello (1):
    • SSLv3, TLS handshake, Finished (20):
    • SSLv3, TLS change cipher, Client hello (1):
    • SSLv3, TLS handshake, Finished (20):
    • SSL connection using ECDHE-RSA-AES256-SHA
    • Server certificate:
    • subject: C=CN; ST=Beijing; L=Beijing; O=XiaoMi
    • start date: 2014-05-14 12:50:20 GMT
    • expire date: 2024-05-11 12:50:20 GMT
    • SSL: unable to obtain common name from peer certificate
    • Closing connection #0
    • SSLv3, TLS alert, Client hello (1):

    Here's
    #openssl x509 -in server.crt -text -noout

    Certificate: Data: Version: 1 (0x0) Serial Number: 15298562268347408844 (0xd44f6953eb0aa1cc) Signature Algorithm: sha1WithRSAEncryption Issuer: C=CN, ST=Beijing, L=Beijing, O=OKK, OU=Test, CN=MyComp Validity :

  • Mark
    Mark about 9 years
    Disabling SSL certification verification generally a bad idea and a poor hack. If the intent is to provide any guarantee against a MITMA then disabling the verification causes the guarantee to fail.
  • Little Code
    Little Code about 9 years
    @Mark... I know that, but its pretty much what he's asking for.... look, he's using Self-Signed certificates anyway !
  • Mark
    Mark about 9 years
    Unfortunately an all too common view. The dirty little secret of all CA's is their root is always self signed. You can actually build your own CA and trust chains based off of a self signed root certificate. This works well for internal communication of systems and network components to verify the parties involved are trusted.