I'm to the part of my efforts where I'm trying to create the token needed to send to the partner.

The error suggests that my token information isn't right.  

Here are the excerpts from my call.  I've cut a lot of data out of this for brevity.

EXIT DATA LEN:00000000
SRC KEYID LEN:00000064
SRC KEYID    :KEKEK.TEST   (CKDS label.  I've browsed the file and confirmed it is there.  This points to an internal token for an EXPORTER key.)
UNW KEYID LEN:00000000  (unwrap token not needed)
RAND TOKN LEN:00000034  (Freshness information)
RAND TOKN    :     f f7  (This starts with x'3020060A2A...'
CRL BUFFR  LEN:00000728
CRL BUFFR     :MIICHjCCAQYCAQ  (base 64 encoded object)
CREDKDH BFLEN:00000904
CREDKDH BFR  :MIICoDCCAYgC  (base 64 encoded object)
CREDKRD BFLEN:00002276
CREDKRD BFR  :MIIGpjCCBY6gAw  (base 64 encoded object)
PRIV RSA  LEN:00000064
PRIV RSA     :RSAMARK.HOSTPAIR  (Label for a prior generated pub/priv rsa keypair for signing)
OPT BLKS  LEN:00000000  (not optional blocks)
TRNSPORT  LEN:00003500  (I have a buffer of 3500 bytes to accept the result of the call

For the life of me, I can't figure out where I went wrong.   Would anyone like to take a gander at my information and point out what I just can't see?  I would appreciate the help.

------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
------------------------------

I'm still looking for some help on this question.  Please help me if you can.

Sincerely,
Mark Vollmer

While we don't have an answer for you yet, we are looking to understand what might be going on here. Thanks for your patience.

Believe me, I'm so very thankful for the help.  I'm lucky that this is not due for completion anytime soon.  I have lots of time to figure this out.  Of course, management may change that.

The value is decimal 181

------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
------------------------------

One clarification: Are you seeing reason code of 181 decimal or 181 hex? both are possible and both point in completely different directions, unfortunately.

Also, can you please provide all the rules?

------------------------------
Eric Rossman
------------------------------

I think I understand the problem. Both the cred_kdh and cred_krd parameters must be either DER encoded or PEM. It looks like you are passing bare Base64 encoded text instead of the PEM format:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Not all certificates will have that exact header and footer but will have something similar.

So, I believe you can either Base64 decode what you have to get the binary DER encoding or ensure that you are passing the full PEM-encoded certificates with the header and footer.

Thanks, I'll update to use the full PEM format.   I didn't think that data was terribly important to the certificate so I omitted it.

I'll reach back out when I get a chance to test this.

Sincerely,
Mark Vollmer

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

When we add the Begin & End certificate information, should they be just the text, or should fill a 64 byte or 80 byte line?

-----BEGIN CERTIFICATE-----MIIDQ...

or

-----BEGIN CERTIFICATE-----                                     MIIDQ...

I'm not clear on how the call will parse the PEM format.

Sincerely,
Mark Vollmer

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

I am not sure that the card actually cares, but I would think that trailing blanks are unneeded since they are not present in the original PEM format.

-----BEGIN CERTIFICATE-----MIIDQ...

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----