I hit this before working with a customer and tracked it down, it's an issue with relayd (even a current relayd) on FreeBSD 10.x and the ciphers offered by the web server(s). I setup a local test and with a default apache 2.4 SSL setup it works:
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
It fails with other cipher lists such as:
SSLCipherSuite RC4:TLSv1:-MD5:-aNULL:-MED:-LOW:-EXP:-NULL
It also fails with the cipher list given in the apache config example for "speed optimized" and it also fails with the cipher list we use for the pfSense GUI (on 2.2 at least, it has changed since my last test).
If I place some other cipher first such as AES128-SHA, or HIGH for example, it starts to work again.
It's still not clear if it's a relayd quirk, or something specific to FreeBSD, or OpenSSL, etc. About the only thing I haven't tried is a test purely on OpenBSD which wouldn't be as useful but may at least show if it's specific to relayd rather than the other factors.
At least we know that adjusting the SSLCipherSuite should be able to get it working again, though perhaps not an ideal solution, it's as far as we can take it ourselves. It'll need to be reported upstream to FreeBSD and/or the relayd maintainer (See http://www.freshports.org/net/relayd/ for contact info ) for a proper long-term resolution.
I've tried it with relayd (current version from pfSense and the latest in FreeBSD ports) on pfSense and FreeBSD directly and the problem was present there as well, so it is not specific to pfSense.
As an alternative, use the HAProxy package which is better in this role in nearly every way.
The /var/etc/relayd.conf file may be taken from pfSense and placed onto any FreeBSD box with relayd installed to test.