4

I have a server, which has a self signed certificate, which I am trying to securely access. I've got the certificate by looking at the output from openssl s_client -connect <ip>, and copied it to testcert.pem, which I then tried to use with curl --cacert testcert.pem <url>. However, this didn't work, and my research has lead me believe that the problem may be the line in the certificate that reads Subject: CN=id23946.

Apparently, I need to store an alias somewhere on my system linking id23946 to the ip address, but I can't find any information on how to do that. So, how do I do it? How do I make curl verify this certificate as valid?

Edit: I am aware that I can connect to the server by adding <ip> id23946 to my hosts file and then using id23946 as the address, but I would really prefer to be able to connect directly to the server's actual address, without having to modify the server certificate. Is there any way to do that?

Benubird
  • 523
  • 1
  • 5
  • 11
  • Not really an answer but look up Subject Alternative Name (SAN), kind of like CN records for certs. http://www.symantec.com/page.jsp?id=san-ssl-certificates – TheFiddlerWins Aug 19 '13 at 14:18
  • Yeah. I added a small comment about SAN to [my answer to your other question](http://serverfault.com/a/532028/162751). – Etan Reisner Aug 19 '13 at 14:19

1 Answers1

4

Unfortunately there is not a way to do what you want, outside of obtaining a new certificate which contains e.g. Subject Alternative Name (SAN) extensions for the other DNS names/IP addresses by which your TLS client would contact that server.

The reason is that this "aliasing" needs to be trustable by the X509 verification process, and the only thing that makes for trustable binding of information -- including aliases like "this subject/cert is also associated with DNS name site.example.com and IP address 1.2.3.4" -- is to have these aliases/associations contained within the certificate itself. The verification process trusts the signing certificate, and thus the issuing certificate's signature needs to encompass everything about that subject, including aliases. Everything that the issuing certificate asserts to be valid is contained within the certificate itself.

Another way to think about this is "if it's not signed by the issuing certificate, then it can't be trusted".

Castaglia
  • 3,349
  • 3
  • 21
  • 42