On 12/07/2015 22:01, Thomas Herchek wrote:
Hi,

Sometimes, during the processing of an HTTP cert response from the Symantec PKI Manager SCEP server, our application encounters an error condition while validating the certs attributes. The error that we see is "Transaction not permitted or supported".

It appears that this error is detected either in the ASN1_TYPE_get() function or the OBJ_nid2obj() function.

Can you tell me, what conditions might cause this type of failure when unwrapping and validating a cert response?

Here is a snippet of our code that detects this condition:

                /* Get signed attributes */

                attribs = PKCS7_get_signed_attributes(si);

                if (attribs == NULL)

                {

ReportAPIError("[PKCS7_UnWrap] No attributes found in PKCS#7 data", szErr);

                                goto cleanup;

                }

                ...

                /* Get pkiStatus */

if ((i = get_signed_attribute(attribs, nid_pkiStatus, V_ASN1_PRINTABLESTRING, &p)) == 1)

                {

ReportAPIError("[PKCS7_UnWrap] Failed to get the signer pkiStatus attributes", szErr);

                                goto cleanup;

                }

                /* Get failInfo */

                if (atoi(p)!= SCEP_PKISTATUS_SUCCESS)

                {

                                if (atoi(p) == SCEP_PKISTATUS_FAILURE)

                                {

if ((i = get_signed_attribute(attribs, nid_failInfo, V_ASN1_PRINTABLESTRING, &p)) == 1)

                                                {

ReportError("[PKCS7_UnWrap] Cannot find failInfo", szErr);

goto cleanup;

                                                }

                                                switch (atoi(p))

                                                {

                                                case SCEP_FAILINFO_BADALG:

ReportError("[PKCS7_UnWrap] Unrecognized or unsupported algorithm ident", szErr);

break;

case SCEP_FAILINFO_BADMSGCHK:

ReportError("[PKCS7_UnWrap] Integrity check failed", szErr);

break;

case SCEP_FAILINFO_BADREQ:

ReportError("[PKCS7_UnWrap] Transaction not permitted or supported", szErr);

break;

case SCEP_FAILINFO_BADTIME:

ReportError("[PKCS7_UnWrap] Message time field was not sufficiently close to the system time", szErr);

break;

case SCEP_FAILINFO_BADCERTID:

ReportError("[PKCS7_UnWrap] No certificate could be identified matching", szErr);

break;

default:

ReportError("[PKCS7_UnWrap] Wrong failInfo in reply", szErr);

                                                }

                                }

                                else

                                {

ReportAPIError("[PKCS7_UnWrap] PKI Status: Not success", szErr);

                                }

                                goto cleanup;


As I read the code you quoted above, all values of pkiStatus come from whomever signed the PKCS#7 message (Symantec?). Specifically, the message contained inside it a digitally signed extension attribute of type "pkiStatus" with a value of SCEP_FAILINFO_BADREQ .

If my interpretation is right, this means you need to look at why the SCEP server (or whatever else returns that PKCS#7 message) returned SCEP_FAILINFO_BADREQ.

I don't know much about SCEP specifically, so I cannot dig deeper into this myself.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to