Certificate inspection logic

[Vladimir_Ostrovsky]

Hi all,

I read about certificate inspection feature and I don't quite understand its logic. According to this KB article, for instance, all it does is checking CN field of the server-sent certificates to the web filter policies. Is it all it can do?

[ul]

What about SAN field, is it checked?

What about checking CN or SAN hostnames against the SNI value sent by the client? Is it done?

What about setting constraints on the certificate chain? For instance, I know that all Google sites are equipped with certificates issued by GlobalSign. Can I set "certificate inspection" profile to verify that certificate received from https://mail.google.com is indeed signed by GlobalSign CA cert? Can it be done for all sites under the google.com domain? Is it possible with regular firewall policies or with proxy policies?[/ul]

Does anybody know answers to these?

Thanks,

Vladimir.

[Vladimir_Ostrovsky]

This should be essentially the same as the use of "[link=https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT]CONNECT hostname:443 HTTP/1.1[/link]" header by Explicit Proxy for HTTPS connections. The Proxy also responds to TCP handshake, then reads this header and makes decisions based on this hostname.

I'm just looking for a way to implement the same thing without using the Explicit Proxy.

[emnoc]

[ul]

What about SAN field, is it checked?

What about checking CN or SAN hostnames against the SNI value sent by the client? Is it done?[/ul]

Yes webfilter for example is looking at CN name if a altName is not present. If altName is being used, CN field is ignored. All browsers ( modern ) do not care about CN when altName fields is being used btw.

What about setting constraints on the certificate chain? For instance, I know that all Google sites are equipped with certificates issued by GlobalSign. Can I set "certificate inspection" profile to verify that certificate received from https://mail.google.com is indeed signed by GlobalSign CA cert? Can it be done for all sites under the google.com domain? Is it possible with regular firewall policies or with proxy policies?

That would be a no, other means are design for certificate issuer verification. CAA type257 comes to mind.

http://socpuppet.blogspot.com/2016/04/dns-caa-records-for-certifications.html

Very few ever uses this DNS resource-record but google is a major player that does. So unless you had a DNS record and means for querying for the type257 value you could validate the certificate not being forged from the start.

So let's say some one build a cert www.yourdomain.com  and have it signed by a trusted CA ( i.e let's Encrypt ) and then hijack the real site "www.yourdomain.com", and installed the phony site, a end-user would have no clue since the certificate issued by let'sencrypt in this example would most likely be trusted by the browser.

I don't think any NGFW has that level of a deep of a "certificate" inspection capabilities imho.

Ken Felix

[Vladimir_Ostrovsky]

Yes webfilter for example is looking at CN name if a altName is not present. If altName is being used, CN field is ignored. All browsers ( modern ) do not care about CN when altName fields is being used btw.

Nice to know, thank you!

About CAA records - they do prevent well-mannered CAs from issuing certificates for domains having them, but this is not a problem I'm trying to solve. I don't own a destination server or its domain, I'd like to make sure that when users in my network open HTTPS connection to [link=https://somewhere.com,][link]https://somewhere.com[/link],[/link] they indeed receive certificate issued by a trusted CA for somewhere.com - and not just some certificate with "somewhere.com" written in CN or SAN fields.

I don't think any NGFW has that level of a deep of a "certificate" inspection capabilities imho.

If so, this is strange - maybe I'm spoiled, but it seems as very natural capability to me. :)

[DanielW]

Did you find any answers? Especially to the SAN question?