Three of the answers presently contributed require lowering the security level of your browser, possibly leaving you open to various attacks if you do this in your primary browser, subsequently use that browser for other web sites, or simply forget to revert this change (or multiple changes).
Legacy and insecure SSL/TLS features (SSLv2 and SSLv3, SHA1RSA signatures, RC4 and 3DES ciphers, MD5 MAC, export ciphers, non PFS ciphers, <1024 DH parameters) are progressively being disabled by default and/or removed from browsers, and for good reason.
A separate problem that @AndreKR helpfully flags is that of browser compatibility, in which case a legacy browser in a dedicated VM is probably the most robust solution.
If you cannot replace the device, use dedicated VM or a dedicated browser. The next best option is a TLS proxy to allow the use of a contemporary secure browser. Enabling one, (or two, or three ...) insecure features in a browser is not a secure and sustainable solution, and when the inevitable happens and a required feature is removed entirely? (SSLv3 support for Chrome, Opera, Firefox).
A secure alternative is to proxy the connections through something that supports both old/legacy and new protocols & ciphers, there are many options (including the rather heavyweight solution of an Apache reverse proxy).
The following more lightweight solution should work on both *nix and Windows systems. This will require that you generate a key/cert — not necessarily a problem since the next thing that's going to happen is that contemporary browsers will reject SHA1-signed certificates. This way you can use a SHA-2 signed RSA-2048 certificate and contemporary TLS for access to the device.
For this example:
socat proxy
Using socat:
CERT="cert=mydevice.crt,key=mydevice.key"
SSLSRV="cipher=AES256-SHA,method=TLS1.2,verify=0"
SSLCLI="cipher=AES128-SHA,method=SSL3,verify=0"
socat \
OPENSSL-LISTEN:11443,bind=127.0.0.1,reuseaddr,fork,$CERT,$SSLSRV \
OPENSSL:192.168.1.123:443,$SSLCLI
and connect to https://127.0.0.1:11443/
Notes
Amend your local hosts file to prevent certificate name mismatch warnings from your browser if needed, since you need an internal certificate for this anyway you can generate a certificate with the expected internal name (unlike many devices which I have encountered which tend to use odd or unfriendly names for certificates).
For TLSv1.2 support you will need OpenSSL-1.0.1 or later, and socat-1.7.3.0 or later. The cipher and method options can be adjusted according to requirements, as can the server or client certificate verification.
This solution extends to even similar problems, such as SSLv2 only devices, or with 512-bit certificates or a hobbled set of ciphersuites, though you will need to make sure that OpenSSL was not built with no-ssl2 or no-ssl3 and has the relevant ciphersuite enabled.
If I was an auditor I'd rather see documented access method (along with an upgrade plan!) than an ad hoc solution which is an accident waiting to happen.
