Description of problem:

The latest ssl.py file tries to validate hostnames vs certificates but includes a faulty regexp which causes any wildcard domains (e.g. *.s3.amazonaws.com) to fail validation. 

Version-Release number of selected component (if applicable):
python-libs-2.7.5-34.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. I'm using the s3cmd tool which tries to establish an SSL connection to Amazon S3:

s3cmd sync -c ./data/s3.cfg -v -m text/css -P /tmp/svplanet/english/html/*.css s3://planet.sofiavalley.com/

however this can be even more easily reproduced.

>>> import ssl
>>> ssl._dnsname_match("*.s3.amazonaws.com", "planet.sofiavalley.com.s3.amazonaws.com")
>>> 


2.
3.

Actual results:


Expected results:
<_sre.SRE_Match object at 0x1474030> - the function should match the provided domain and hostname.

Additional info:

The following patch fixes the issue:

# diff -u ssl.py.orig ssl.py
--- ssl.py.orig	2015-11-24 14:22:58.490693826 +0200
+++ ssl.py	2015-11-24 14:57:35.777738043 +0200
@@ -214,7 +214,7 @@
     if leftmost == '*':
         # When '*' is a fragment by itself, it matches a non-empty dotless
         # fragment.
-        pats.append('[^.]+')
+        pats.append('^.+')
     elif leftmost.startswith('xn--') or hostname.startswith('xn--'):
         # RFC 6125, section 6.4.3, subitem 3.
         # The client SHOULD NOT attempt to match a presented identifier


From Python's documentation:

[]

    Used to indicate a set of characters. In a set:

...
        Special characters lose their special meaning inside sets. For example, [(+*)] will match any of the literal characters '(', '+', '*', or ')'.

^^^^^^^^^ this is the cause of the error