The answer, obviously, is NO, I think. I am no expart of SSL/TLS, so correct me if I am wrong.

Think of the Man-in-the-middle attack.
By DNS cache poisoning etc., the client may be led to a rogue site with SSL. SSL certificates are now cheap. Some offers at only $14.95 while average intake by phishers are around $4000 per attack. Although many people argue that phishers will not buy a certificate, that may not be true, as they can easily pay for it. Certificates are cheap compaired to renting a bot-net, which costs around $1500 a day.

I have strayed.

Now, back to man-in-the-middle scenario. Think of something like this:

Client ( C ) – Rogue SSL Proxy (RSP) – Real Server (S)

The client establishes SSL session with RSP. RSP establishes one in turn with RS. Suppose that you were relying on non PKI authentication mechanism like username:password authentication. Then, you are undone. RSP learns your username and password, and logs into S and do transactions on behalf of you.

To be safe, C has to check the X.509 of S in a particular manner. X.509 itself is a public information, so is prone for replay attack. C has to get something signed by the private key and returned it to it to trust the other end. Luckily, in TLS, we have something like that. During the handshake, C sends out the premaster secret encrypted with S’s public key. (Premaster secret acts as seed for the TLS session establishment, so it cannnot be missed.) So, if C uses preshared public key of S in this phase instead of something C got from the network now, then, this kind of man-in-the-middle become impossible. In another word, just establishing SSL/TLS session with somebody is not enough. Some like SAML-bindings documents suggests checking DN or AltName but that is also probably is not enough. Establishing TLS session and the public key being equal to the one used in establishing the session would guarantee the safety.

Now, how many of you are doing that?

[References]
http://www.atmarkit.co.jp/fnetwork/rensai/cell05/ssl1.html
http://www.atmarkit.co.jp/fdotnet/special/wse02/wse02_03.html