I need to match a host name to a wildcard that is in the alternative names list.
common name: *.b.hosting.com
alternative: *.b2.hosting.com, *.b3.hosting.com, *.a.hosting.com. *.a1.hosting.com,...
This fails the matching host name, matching wildcard name, and matching alternative names test, resulting in a "common name mismatch" block page.
On the default "SSL Scanner" rule set there is a rule under SSL Scanner > Certificate Verification > Verify Common name (proxy setup) > Allow alternative common names. Is this the rule you are modifying? If so, keep in mind by default this rule's criteria is URL.Host is in list Certificate.SSL.AlternativeCNs', perhaps this needs to be changed 'matches in list' instead which would allow for wildcards as you see in the alternative names.
Please let me know if this helps.
What is the example site so I can check myself?
~JonMessage was edited by: Jon Scholten on 1/19/11 5:02:32 PM CST
You assumed correctly, I'm using the default SSL Scanner rule set. I tried changing to "matches in list", but that also requires changed the operand accordingly. I haven't found the right combination yet.
We match the 4th alternative wildcarded name. The default ruleset doesn't acount for this.
Common name: *.na1.force.com
Alternative subject names: *.na1.force.com, *.na2.force.com, *.na2.visual.force.com, *.secure.force.com, *.na1.visual.force.com, *.na3.force.com, *.na4.force.com, *.na2.content.force.com, *.na1.content.force.com, *.na3.visual.force.com, *.force.com, *.na4.content.force.com, *.na3.content.force.com, *.na4.visual.force.com
To select "matches in list" you have to use MWG 7.0.2 or higher, because the operator is only allowed for a WILDCARD list and not for a STRING list.
Have you found a way to match the host name against the alternative subject names when they contain wildcards.
I'd also like to be able to test the host name against wildcards in certificate's alternative subject names but I can't figure out how to make a wildcard list from a string list in order to use the 'match in list' operator in a rule.
Having a Certificate.SSL.AlternativeCNs.ToWildCard property would be useful.
I encounterd this issue with YouTube's satellite sites like i3.ytimg.com :
Common name: *.google.com
Alternative subject names: *.google.com, google.com, *.atggl.com, *.youtube.com, *.ytimg.com, *.google.com.br, *.google.co.in, *.google.es, *.google.co.uk, *.google.ca, *.google.fr, *.google.pt, *.google.it, *.google.de, *.google.cl, *.google.pl, *.google.nl, *.google.com.au, *.google.co.jp, *.google.hu, *.google.com.mx, *.google.com.ar, *.google.com.co, *.google.com.vn, *.google.com.tr
As a workarround, I can add the certificate in "Certificate White List" in order to skip the certificate verification for this site, but I'd have to do this for each and every satellit host (eg. i1.ytimg.com, i2.ytimg.com, ...).
The default SSL scanner ruleset doesn't take into account wildcard alternative subject. The URL.Host is only checked against possible wildcards present in the subject of the certificate.
In order to allow hosts matching wildcards present in the alternative subject you must add a rule to the default ruleset.
Such a rule has been given in the following thread : https://community.mcafee.com/thread/34068
I have tested this solution and it works. Here is a snapshot of the ruleset in production on my appliances. I use a different regex than the one given in previous thread.
Where are these Unresolvable certificates being recorded to update this graph?
What does Unresolvable mean? Anyone else have this issue?Message was edited by: jont717 on 4/8/11 1:07:55 PM EDT