For testing purposes a
{@link nl.nikhef.slcshttps.TestSURFCA#main(String[]) main()} method is provided
by {@link nl.nikhef.slcshttps.TestSURFCA}, which shows
{@link nl.nikhef.slcshttps.PKCS12Https} and
{@link nl.nikhef.slcshttps.SURFCAHttps}. It can be called using e.g.:
java -D... -jar slcshttps_jdk15_v0.1.jar "https://www.nikhef.nl/~msalle/cert/showcert?nohtml=1"where ... denote any of the following properties:
nl.nikhef.slcshttps.CERT_URL
nl.nikhef.slcshttps.AUTH_URL
http(s)://
or uses it as a postfix to the value of
nl.nikhef.slcshttps.CERT_URL
and then adds the CSR hash. Used by
{@link nl.nikhef.slcshttps.SURFCAHttps}.
nl.nikhef.slcshttps.comm
stdio
or popups for user
communication by classes {@link nl.nikhef.slcshttps.SURFCAHttps}, {@link
nl.nikhef.slcshttps.PKCS12Https} and {@link
nl.nikhef.slcshttps.trust.TrustManagerImpl}. For SURFCAHttps
another way to communicate is used by the {@link
nl.nikhef.slcshttps.gui.SURFCAInitDialog} which hence also ignores this setting
by implementing and empty {@link
nl.nikhef.slcshttps.SURFCAHttps.SURFCACommunicator}. Other applications using
this package probably want to provide their own implementations of these
communicator interfaces
{@link nl.nikhef.slcshttps.SURFCAHttps.SURFCACommunicator},
{@link nl.nikhef.slcshttps.PKCS12Https.PKCS12Communicator} and
{@link nl.nikhef.slcshttps.trust.TrustManagerImpl.TrustCommunicator}.stdio popup
nl.nikhef.slcshttps.https
"mask"
, which means it's behaving as if only
HttxURLConnection
is used, but in practise also
HttpsURLConnection
is setup for using the client side certificates.
Value "both"
does practically the same except for the
{@link nl.nikhef.slcshttps.gui.CAPanel}/{@link
nl.nikhef.slcshttps.gui.SerialPanel} classes: value "both"
will
show for both HttpsURLConnection
and HttxURLConnection
which certificate is in use for client side authentication, while value
"mask"
will only show HttxURLConnection
(although both
will be set).https httx both mask
nl.nikhef.slcshttps.acknowledge
true false