Hi,

>
> > > +static const CRYPT_OID_INFO *
> > > +find_oid(DWORD keytype, const void *key, DWORD groupid, bool
> > > +fallback) {
> > > +    const CRYPT_OID_INFO *info = NULL;
> > > +
> > > +    /* force resolve from local as first step */
> > > +    if (groupid != CRYPT_HASH_ALG_OID_GROUP_ID &&
> > > +        groupid != CRYPT_ENCRYPT_ALG_OID_GROUP_ID &&
> > > +        groupid != CRYPT_PUBKEY_ALG_OID_GROUP_ID &&
> > > +        groupid != CRYPT_SIGN_ALG_OID_GROUP_ID &&
> > > +        groupid != CRYPT_RDN_ATTR_OID_GROUP_ID &&
> > > +        groupid != CRYPT_EXT_OR_ATTR_OID_GROUP_ID &&
> > > +        groupid != CRYPT_KDF_OID_GROUP_ID)
> > > +    {
> >
> > Why not do the local lookup for all grupids? Anyway you are falling
back to
> > domain-wide look up if this fails.
>

> > Simply because Microsoft does it this way in their generic wrapping of
> CryptFindOIDInfo for certificate selection helpers:
> https://github.com/dotnet/runtime/blob/01b7e73cd378145264a7cb7a09365b41ed42b240/src/libraries/Common/src/Interop/Windows/Crypt32/Interop.FindOidInfo.cs#L51
> ff - the groups excluded here will always be looked up locally, independent
> of the CRYPT_OID_DISABLE_SEARCH_FLAG, so that we can save one call for them.


>
> > > +        info = CryptFindOIDInfo(keytype, (void*)key, groupid |
> > CRYPT_OID_DISABLE_SEARCH_DS_FLAG);

You are misreading the usage in dotnet sources. Their reasoning is that for
those listed algorithms AD will not be consulted and there is no need to
explicitly add the DISABLE_SEARCH_FLAG. But adding it doesn't hurt and
simplifies the code.

So change the above to

info = CryptFindOIDInfo(keytype, (void*)key,
groupid|CRYPT_OID_DISABLE_SEARCH_DS_FLAG);

with no if clause. That way we first search without querying the AD
irrespective of the algorithm.

> > > +    }
> > > +
> > > +    /* try proper resolve if not found yet, also including AD */
> > > +    if (!info)
> > > +    {
> > > +        info = CryptFindOIDInfo(keytype, (void*)key, groupid);
> >
> > How long would this take to time out -- we try to avoid calling
functions that
> > need network access to the DC as that's often not available before the
tunnel
> > comes up.
>
> Good question which I hadn't taken into account so far; from what I've
seen on machine clients I've deployed that select their certificate using
this logic, the timeout is almost instantaneous, i.e. CryptFindOIDInfo does
not find an object for the TMPL: parameter if it can't reach the domain. Of
course, your note generally limits the functionality of actually using
CryptFindOIDInfo to resolve a printable template name from a specific
domain to an OID (which is then found in the actual certificate), but I
wouldn't take this out if it doesn't introduce a long delay (possibly,
there are two tunnels in some cases, where an independent tunnel sets up
reachability of the domain).

Actually there are reports out there that CryptFindOIDInfo can take a long
while to timeout if AD is unreachable. To make things worse we are here
querying the AD two times one with groupid and second time for all groups.
But we can't do much about it except to add a caveat that anyone using
template match should be aware of it.

Please also update the man page (description of --cryptoapicert).

Selva
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to