This is not surprising, since the inventors of these fields have only thought
about a format but not about an associated service implementable via an APIso that you can ask: "Is this cert good for domain/host xyz". Instead of that the implementations extract sometimes the first or the last occurence of common
name, or just the first occurrence of subjectAltNames.Or, there was the idea to have "Give me the domain that this cert is good for"
which is something that doesn't work.
In gsoap : stdsoap2 you find a typical example:X509_NAME_get_text_by_NID(X509_get_subject_name(peer), NID_commonName, soap->msgbuf, sizeof(soap->msgbuf));
X509_free(peer);
if (soap_tag_cmp(soap->msgbuf, host))
{ soap_set_sender_error(soap, "SSL error", "SSL certificate host
name mismatch in tcp_connect()", SOAP_SSL_ERROR);
soap->fclosesocket(soap, (SOAP_SOCKET)fd);
return SOAP_INVALID_SOCKET;
}
Compare this to the test in the curl library, the function verifyhost in
lib/ssluse.c which I
you could get from curl.haxx.se
However, it still doesn't work! Now my certificates appear to be defined properly, I have done a bit of further testing and it seems that the gSOAP library I am using is ignoring any subjectAltName parts and only checking the commonName field. I'm going to go and check the gSOAP docs and groups to see if this is the case.
smime.p7s
Description: S/MIME Cryptographic Signature
