*.net? How about
The RFC 2818 does not say anything about this topic.
Yes, it can be issued.
Luckily the common browsers do not accept wildcard certificates for TLDs.
IE even rejects *.co.uk, but I am pretty sure the list is not complete.
In the list of fake certificates issued by DigiNotar, there is "*.*.com". This is obviously an attempt to get around the restriction.
I have tested this on common browsers, the three big ones (on windows anyways) don't accept this. What I haven't done is try it on the mobile platforms which imo are the real target of this attack. Since iOS doesn't have a way to revoke certificates there are millions of i-devices out there that are vulnerable until apple releases a patch, and they apply it.
Obvious places to try this with high impact: Activesync to exchange, ssl vpn clients, safari on idevices, stock browser on androids.
For the issuing part, everything can be put in a certificate. That a name is "wildcard" has no special significance for the CA. The CA puts a string as
What matters is what SSL clients will accept as a "valid certificate", i.e. a certificate including a name which "matches" the intended server name (the one included in the URL). This is nominally specified in RFC 2818, section 3.1, and it allows many kinds of wildcard names, including things like "
So browser vendors made their own schemes and restrictions. Much later, a new RFC (6125, from March 2011) was published, with section 6.4.3 dedicated to the processing of wildcard names in certificates. What RFC 6125 describes is more in tune with the reality, and is a "proposed standard", so there is at least some will, at some level, to make it happen. However, nothing in RFC 6125 mandates rejection of