SSL fails due to IP SANs check

[mikew...@gmail.com]

When connecting to a server with a self signed certificate I am getting the following message.

x509: cannot validate certificate for 172.23.107.26 because it doesn't contain any IP SANs

I understand the reason for this error and how to fix it, but I'm curious why we need to make sure that the CN name matches one of the IP addresses in the SANs list. What is the security vulnerability that results from skipping this check?

Thanks,

- Mike

[Brad Fitzpatrick]

I assume you're connecting to the cert by IP, instead of by name? I think you have to use its DNS name for how you've made your cert. If you're going to connect by IP, you would need different fields in your cert to permit that.

Some background: https://github.com/golang/go/issues/4658

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mikew...@gmail.com]

Thanks for the response. I spent most of the day looking into this yesterday before I found good information as to why this is required. Basically what I found was that the issue is that the Common Name field of the certificate can contain wildcards and this is problematic because you could technically use a wildcard with an ip address which would make a whole range of ip addresses valid for a certificate. As a result any certificates that reference ip addresses need to have a SANs section that explicitly list all valid ip addresses so that there are no security vulnerabilities. One of the remaining questions I had though was whether or not there is any problem with an ip address that does not contain wildcards in the Common Name field, but I could not find any information about how that could cause a security vulnerability. It might not, but the x.509 specification state clearly that you shouldn't do this so it may not work for clients other than golang too.

In any case pretty much everything I read also highly recommended against having certificates with ip address anyways. It's not something I would do in production, but for testing it's nice to be able to generate a certificate with an ip address.

Anyways, if anyone has any information about how the full ip address in the common name can cause a security vulnerability I'd be interested to know.

http://www.westpoint.ltd.uk/advisories/wp-10-0001.txt

https://tools.ietf.org/html/rfc2818

- Mike

[sarrabahro...@gmail.com]

Please how can i solve thé issie