Josh Soref
b3ab7a48cc
* accumulating * acquire * alignment * appropriate * argument * assign * attribute * authenticate * authentication * authenticator * authority * auxiliary * brackets * callback * camellia * can't * cancelability * certificate * choinyambuu * chunk * collector * collision * communicating * compares * compatibility * compressed * confidentiality * configuration * connection * consistency * constraint * construction * constructor * database * decapsulated * declaration * decrypt * derivative * destination * destroyed * details * devised * dynamic * ecapsulation * encoded * encoding * encrypted * enforcing * enumerator * establishment * excluded * exclusively * exited * expecting * expire * extension * filter * firewall * foundation * fulfillment * gateways * hashing * hashtable * heartbeats * identifier * identifiers * identities * identity * implementers * indicating * initialize * initiate * initiation * initiator * inner * instantiate * legitimate * libraries * libstrongswan * logger * malloc * manager * manually * measurement * mechanism * message * network * nonexistent * object * occurrence * optional * outgoing * packages * packets * padding * particular * passphrase * payload * periodically * policies * possible * previously * priority * proposal * protocol * provide * provider * pseudo * pseudonym * public * qualifier * quantum * quintuplets * reached * reading * recommendation to * recommendation * recursive * reestablish * referencing * registered * rekeying * reliable * replacing * representing * represents * request * request * resolver * result * resulting * resynchronization * retriable * revocation * right * rollback * rule * rules * runtime * scenario * scheduled * security * segment * service * setting * signature * specific * specified * speed * started * steffen * strongswan * subjectaltname * supported * threadsafe * traffic * tremendously * treshold * unique * uniqueness * unknown * until * upper * using * validator * verification * version * version * warrior Closes strongswan/strongswan#164.
19 lines
1.0 KiB
Plaintext
19 lines
1.0 KiB
Plaintext
This scenario tests the <b>strictcrlpolicy=ifuri</b> option which enforces a
|
|
strict CRL policy for a given CA if at least one OCSP or CRL URI is known
|
|
for this CA at the time of the certificate trust path verification.
|
|
On the gateway <b>moon</b> two different Intermediate CAs control the access
|
|
to the hosts <b>alice</b> and <b>venus</b>. Access to <b>alice</b> is granted
|
|
to users presenting a certificate issued by the Research CA whereas <b>venus</b>
|
|
can only be reached with a certificate issued by the Sales CA.
|
|
<p>
|
|
The roadwarrior <b>carol</b> has a certificate from the Research CA which does not
|
|
contain any URIs. Therefore a strict CRL policy is <b>not</b> enforced and the
|
|
connection setup succeeds, although the certificate status is unknown.
|
|
</p>
|
|
<p>
|
|
The roadwarrior <b>dave</b> has a certificate from the Sales CA which contains
|
|
a single OCSP URI but which is not resolvable. Thus because of the known URI
|
|
a strict CRL policy is enforced and the unknown certificate status causes the
|
|
connection setup to fail.
|
|
</p>
|