I believe this is undefined behavior for browsers (as it is not defined how to handle this situation) I am assuming with Address based certificate a fully qualified domain name certificate (as in URL://Machine.Domain.TLD) and with a domain based certificate a Wildcard domain Certificate (as in URL://.Domain.TLD).
All browsers I know for now assume the following behavior:
- Get the certificates for the "main" page (e.a. the index.html file or other directly requested file)
- Use this certificate to 'set' the Secure address bar (e.a. the 'lock' symbol)
- Check that NO HTTP request are done, if so change to the broken 'lock' symbol.
- other request can go to any HTTPS location, there are no domain barriers besides the normal ones for HTTP.
As for your second question. this depends on risk and purpose. a wildcard certificate is more expensive, but can be used on more than 1 server. however. because its used on more than 1 place that also means that the secret is known at more than 1 place (the private key) which makes it a higher risk of theft. and because all sub-domains qualify, an attacker can actually USE your certificate for whatever he/she wants without it interfering with your site (e.a. harder to detect misuse).
Also the certificate does not uniquely identify a 'machine' meaning that for critical applications I have not created a full thrust anchor (its missing the last chain).
So a FQDN certificate identifies a 'machine' directly and has only '1' place where the secret is kept which makes it harder to misuse and also means the identity and security chains run right up to the 'machine'.
Whether a 'surfer' can verify the owner of a website is completely up to the skill and knowledge of the surfer. most do not even check for the lock symbol. (You should still implement HTTPS for reasons of spying, security and hijacking)