Safari is unable to establish a secure connection to the server "FamilySearch.org"

This error is beginning to really irritate me as I changed my default web browser from Firefox to Safari earlier this year. This problem only occurs with Safari 6.0.5. It does not occur when using Firefox 23.0.1. Obviously, Firefox is the work around for the problems with Safari.

After connecting to the FamilySearch.org website on port 443 (HTTPS), Safari sends a "Client Hello" packet with the list of encryption algorithms that it is capable of supporting.

The FamilySearch.org server responds with a "Server Hello" packet that identifies that it is willing to proceed using the TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) cipher suite. This cipher suite was in the list provided by Safari in its "Client Hello" packet.

After sending an ACK packet to acknowledge receipt of the FamilySearch.org server certificate, Safari immediately sends a FIN ACK packet to terminate the connection. Safari receives a FIN ACK packet from the FamilySearch.org server and sends an ACK packet to complete closing the connection.

(1) Is this a Safari bug or configuration error that results in the "Client Hello" packet listing a cipher suite that is not supported?

(2) Safari never establishes a connection to the Certificate Authority to validate the certificate. Does Safari have problems with wildcard certificates?

Personally, I discourage the use of wildcard certificates and prefer certificates to be issued with a Common Name (CN) and a list of Subject Alternate Name (SAN) for reliability and security reasons. The wildcard certificate used by FamilySearch.org specifies the CN as *.FamilySearch.org. The certificate would apply to any system under the FamilySearch.org domain but not, necessarily, to the domain itself. Does Safari rigidly implement support for wildcard certificates, i.e. there must be tertiary host name defined for the system?

This introduces another construction that I find distasteful, using the DNS zone name for the name of a web server system in the DNS zone. You can do this but you really need to have an A resource record defined in the zone with the real host name of the web server. You also need to have a PTR resource record in the appropriate IN-ADDR.ARPA DNS zone that points to the real host name of the web server. FamilySearch.org does neither.