Error condition at a customer site

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150713/5af6e415/attachment.html>


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux