[SSL Observatory] public TLS/SSL test server ?

Tom Ritter tom at ritter.vg
Thu May 17 17:28:47 PDT 2012


As part of Jeff Jarmoc's research on SSL Interception Proxies[0] he's
set up some of these tests at https://ssltest.offenseindepth.com/ to
test if an interception proxy was accepting certs it shouldn't.

-tom

[0] http://www.secureworks.com/research/threats/transitive-trust/

On 17 May 2012 19:54, =JeffH <Jeff.Hodges at kingsmountain.com> wrote:
> Hi,
>
> Is there a public TLS/SSL test server ?
>
> It'd be great to have one that offers, on various ports say, and via various
> domain names, server certs and cert chains that are "non-standard" or broken
> in different fashions, e.g....
>
>
> 1. straight-up self-signed end-entity cert, no cert chain offered.
>
>
> 2. expired cert, otherwise legit, chains to public well-known root CA
>
>
> 3. otherwise legit cert, chains to public well-known root CA, but the
> presented CN-ID [1] and DNS-ID do not match the source domain name used to
> initiate the connection.
>
>
> 4. otherwise legit cert, chains to a specified root CA, the CA cert is
> available to the client, however, client is unable to obtain neither a CRL
> nor a OCSP response.
>
>
> 5. otherwise legit cert, chains to a specified root CA, the CA cert is
> available to the client, however, CRL is expired.
>
>
> 6. otherwise legit cert, but is "transvalid" per PeterE's definition..
>
> The transvalid column contains the output of openssl verify called with
> their trusted root repositories /and/ any intermediate CA certs that were in
> the chain presented by that webserver, /plus/ extra intermediate CA certs
> that look like they were missing from the chain presented by the webserver.
>
>
> 7. otherwise legit cert, chains to a specified root CA, the CA cert is
> available to the client, however, contains factorizable public key.
>
>
> 8. others...
>
>
> Having the above would be quite useful for testing various TLS/SSL clients
> against.
>
> Anyone know of one already existing or wish to contribute to setting one up?
>
> thanks,
>
> =JeffH
>
> [1] CN-ID and DNS-ID  are concise PKIX certificate "identifier type"
> designations established in RFC6125 <https://tools.ietf.org/html/rfc6125>.
>
>




More information about the Observatory mailing list