Timestamp for Microsoft Authenticode?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Timestamp for Microsoft Authenticode?

Walter H.
Hello,

has anybody got an idea, how to programm/get such a timestamp server - is not RFC 3161 conform -
with using OpenSSL on Linux;

attached are the ASN.1 dump of the received and sent package - in this case the signtool.exe sends the query to
http://timestamp.verisign.com/scripts/timestamp.dll and receives from there the reply;
- send (request): mssendts-asn1.text
- receive (reply): msrecvts-asn1.text
(these I recorded with wireshark)

I thought of this:

openssl smime -pk7out -in received.der -inform DER -sign -out pkcs7reply.der -outform DER -md sha1 -signer cert.pem -inkey key.pem -passin file:passphrase

but there I'm missing the original 256 bytes of the received query,
and the SECTION with OID 1.2.840.113549.1.9.15 (sMIMECapabilities) is too much;
see the 3rd attachment: pkcs7reply-asn1.text

below is the "spec" from MSDN;

how can I achieve this?

Thanks,
Walter

Time Stamp Request

The time stamp request is sent within an HTTP 1.1 POST message. In the HTTP header, the CacheControl directive is set to no-cache, and the Content-Type directive is set to application/octet-stream. The body of the HTTP message is a base64 encoding of Distinguished Encoding Rules (DER) encoding of the time stamp request.

Although not currently used, the Content-Length directive should also be used in constructing the HTTP message because it helps the time stamp server locate where the request is within the HTTP POST.

Other HTTP headers may also be present and should be ignored if they are not understood by the requestor or time stamp server.

The time stamp request is an ASN.1 encoded message. The format of the request is as follows.

TimeStampRequest ::= SEQUENCE {
   countersignatureType OBJECT IDENTIFIER,
   attributes Attributes OPTIONAL, 
   content  ContentInfo
}

The countersignatureType is the object identifier (OID) that identifies this as a time stamp countersignature and should be the exact OID 1.3.6.1.4.1.311.3.2.1.

No attributes are currently included in the time stamp request.

The content is a ContentInfo as defined by PKCS #7. The content is the data to be signed. For signature time stamping, the ContentType should be Data, and the content should be the encryptedDigest (signature) from the SignerInfo of the PKCS #7 content to be time stamped.

Time Stamp Response

The time stamp response is also sent within an HTTP 1.1 message. In the HTTP header, the Content-Type directive is also set to application/octet-stream. The body of the HTTP message is a base64 encoding of DER encoding of the time stamp response.

The time stamp response is a PKCS #7 signed message signed by the time stamper. The ContentInfo of the PKCS #7 message is identical to the ContentInfo received in the time stamp. The PKCS #7 content contains the signing time authenticated attribute (defined in PKCS #99, OID 1.2.840.113549.9.5).

After Authenticode receives the time stamp from the server, Authenticode incorporates the time stamp into the original PKCS #7 SignedData as a countersignature. To accomplish this, the ContentInfo of the returned PKCS #7 SignedData is discarded, and the SignerInfo of the returned time stamp is copied as a countersignature into the SignerInfo of the original PKCS #7 SignedData. The certificate chain of the time stamper is also copied into Certificates in the original PKCS #7 SignedData as an unauthenticated attribute of the original signer.



msrecvts-asn1.text (22K) Download Attachment
mssendts-asn1.text (856 bytes) Download Attachment
pkcs7reply-asn1.text (24K) Download Attachment
smime.p7s (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp for Microsoft Authenticode?

Jakob Bohm-7
I have written a few posts about this timestamp format on this list
before, here are my supplemental comments to your description and
experiment:

On 3/17/2013 6:14 PM, Walter H. wrote:
> Hello,
>
> has anybody got an idea, how to programm/get such a timestamp server -
> is not RFC 3161 conform -
> with using OpenSSL on Linux;
>

The RFC 3161 protocol postdates the MS format and produces responses
that are useless as PKCS#7/CMS countersignatures (RFC2985#5.3.6), this
may be a "feature" of RFC 3161 due to the horrible patent landscape it
was created in.

The parts of RFC2985/PKCS#9 used by this protocol seem to have been
part of the original 1991 PKCS#9 v1.0.

> attached are the ASN.1 dump of the received and sent package - in this
> case the signtool.exe sends the query to
> http://timestamp.verisign.com/scripts/timestamp.dll and receives from
> there the reply;
> - send (request): mssendts-asn1.text
> - receive (reply): msrecvts-asn1.text
> (these I recorded with wireshark)
>
> I thought of this:
>
> openssl smime -pk7out -in received.der -inform DER -sign -out
> pkcs7reply.der -outform DER -md sha1 -signer cert.pem -inkey key.pem
> -passin file:passphrase
>
Won't work (as you saw), this function doesn't take the actual
ContentInfo structure as input, but data which it will (mis)treat
as an e-mail and then wrap in its own ContentInfo.  Notice how the
messageDigest in your result is not the one in the result from the
original RSADSI/VeriSign/Thawte/Symantec server.

When the input specifies a content type of "data", you could use
the bytes inside the inner OCTET STRING as input to cms like this
    openssl cms -sign -binary -content filewithrawdata.bin -outform DER
to get something close to the right response, but this won't work
if the request specifies a different content type.

> but there I'm missing the original 256 bytes of the received query,
> and the SECTION with OID 1.2.840.113549.1.9.15 (sMIMECapabilities) is
> too much;
> see the 3rd attachment: pkcs7reply-asn1.text
>
> below is the "spec" from MSDN;
>
> how can I achieve this?
>

I think there was a SourceForge project related to this
    (http://sf.net/projects/osslsigncode/)
But I don't know its status.

> Thanks,
> Walter
>
>
>       Time Stamp Request
>
> The time stamp request is sent within an HTTP 1.1 POST message. In the
> HTTP header, the CacheControl directive is set to no-cache, and the
> Content-Type directive is set to application/octet-stream. The body of
> the HTTP message is a base64 encoding of /Distinguished Encoding Rules/
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms721573%28v=vs.85%29.aspx#_security_distinguished_encoding_rules_gly>
> (DER) encoding of the time stamp request.
>
> Although not currently used, the Content-Length directive should also be
> used in constructing the HTTP message because it helps the time stamp
> server locate where the request is within the HTTP POST.
>
> Other HTTP headers may also be present and should be ignored if they are
> not understood by the requestor or time stamp server.
>
> The time stamp request is an ASN.1 encoded message. The format of the
> request is as follows.
>
> Copy
>
> TimeStampRequest ::= SEQUENCE {
>     countersignatureType OBJECT IDENTIFIER,
>     attributes Attributes OPTIONAL,
>     content  ContentInfo
> }
>
> The countersignatureType is the /object identifier/
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms721599%28v=vs.85%29.aspx#_security_object_identifier_gly>
> (OID) that identifies this as a time stamp countersignature and should
> be the exact OID 1.3.6.1.4.1.311.3.2.1.
>
> No attributes are currently included in the time stamp request.
>
> The content is a ContentInfo as defined by PKCS #7. The content is the
> data to be signed. For signature time stamping, the ContentType should
> be Data, and the content should be the encryptedDigest (signature) from
> the SignerInfo of the PKCS #7 content to be time stamped.
>

ContentInfo is defined in RFC2315#7   (PKCS#7) and in RFC5652#3   (CMS)
SignerInfo  is defined in RFC2315#9.2 (PKCS#7) and in RFC5652#5.3 (CMS)

>
>       Time Stamp Response
>
> The time stamp response is also sent within an HTTP 1.1 message. In the
> HTTP header, the Content-Type directive is also set to
> application/octet-stream. The body of the HTTP message is a base64
> encoding of DER encoding of the time stamp response.
>
> The time stamp response is a PKCS #7 signed message signed by the time
> stamper. The ContentInfo of the PKCS #7 message is identical to the
> ContentInfo received in the time stamp. The PKCS #7 content contains the
> signing time authenticated attribute (defined in PKCS #99, OID
> 1.2.840.113549.9.5).

This is RFC2985#5.3.3 signingTime, The OID in the MSDN spec is a
misprint, it is 1.2.840.113549.1.9.5 according to both
the RFC and my dumps of real signatures.

This is also specified in RFC5652#11.3 (CMS).

>
> After Authenticode receives the time stamp from the server, Authenticode
> incorporates the time stamp into the original PKCS #7 *SignedData*
> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa387722%28v=vs.85%29.aspx>
> as a countersignature. To accomplish this, the ContentInfo of the
> returned PKCS #7 *SignedData* is discarded, and the SignerInfo of the
> returned time stamp is copied as a countersignature into the SignerInfo
> of the original PKCS #7 *SignedData*. The certificate chain of the time
> stamper is also copied into Certificates in the original PKCS #7
> *SignedData* as an unauthenticated attribute of the original signer.
>
>

This spec matches my observations and dumps, note that counterSignature
is exactly as defined in RFC2985#5.3.6 and the MS timeStamping protocol
is designed to return a signature that can be used for this.

counterSignature is also specified in RFC5652#11.4 (CMS), however
contrary to the text of RFC5652#11.4, it is acceptable for the
counterSignature to specify a "ContentType" attribute with a value
of "data" (1.2.840.113549.1.7.1), as would be caused by the time
stamping server blindly complying with RFC5652#5.3 as its response is
technically not a counterSignature attribute until after manipulation
by the client.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Timestamp for Microsoft Authenticode?

Ryan Hurst-3
Also this might be useful for implementers:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb931395(v=vs.85).as
px

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jakob Bohm
Sent: Tuesday, March 19, 2013 12:07 PM
To: [hidden email]
Subject: Re: Timestamp for Microsoft Authenticode?

I have written a few posts about this timestamp format on this list before,
here are my supplemental comments to your description and
experiment:

On 3/17/2013 6:14 PM, Walter H. wrote:
> Hello,
>
> has anybody got an idea, how to programm/get such a timestamp server -
> is not RFC 3161 conform - with using OpenSSL on Linux;
>

The RFC 3161 protocol postdates the MS format and produces responses
that are useless as PKCS#7/CMS countersignatures (RFC2985#5.3.6), this
may be a "feature" of RFC 3161 due to the horrible patent landscape it
was created in.

The parts of RFC2985/PKCS#9 used by this protocol seem to have been
part of the original 1991 PKCS#9 v1.0.

> attached are the ASN.1 dump of the received and sent package - in this
> case the signtool.exe sends the query to
> http://timestamp.verisign.com/scripts/timestamp.dll and receives from
> there the reply;
> - send (request): mssendts-asn1.text
> - receive (reply): msrecvts-asn1.text
> (these I recorded with wireshark)
>
> I thought of this:
>
> openssl smime -pk7out -in received.der -inform DER -sign -out
> pkcs7reply.der -outform DER -md sha1 -signer cert.pem -inkey key.pem
> -passin file:passphrase
>
Won't work (as you saw), this function doesn't take the actual
ContentInfo structure as input, but data which it will (mis)treat
as an e-mail and then wrap in its own ContentInfo.  Notice how the
messageDigest in your result is not the one in the result from the
original RSADSI/VeriSign/Thawte/Symantec server.

When the input specifies a content type of "data", you could use
the bytes inside the inner OCTET STRING as input to cms like this
    openssl cms -sign -binary -content filewithrawdata.bin -outform DER
to get something close to the right response, but this won't work
if the request specifies a different content type.

> but there I'm missing the original 256 bytes of the received query,
> and the SECTION with OID 1.2.840.113549.1.9.15 (sMIMECapabilities) is
> too much;
> see the 3rd attachment: pkcs7reply-asn1.text
>
> below is the "spec" from MSDN;
>
> how can I achieve this?
>

I think there was a SourceForge project related to this
    (http://sf.net/projects/osslsigncode/)
But I don't know its status.

> Thanks,
> Walter
>
>
>       Time Stamp Request
>
> The time stamp request is sent within an HTTP 1.1 POST message. In the
> HTTP header, the CacheControl directive is set to no-cache, and the
> Content-Type directive is set to application/octet-stream. The body of
> the HTTP message is a base64 encoding of /Distinguished Encoding Rules/
>
<<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms721573%28v=vs.85%">http://msdn.microsoft.com/en-us/library/windows/desktop/ms721573%28v=vs.85%
29.aspx#_security_distinguished_encoding_rules_gly>

> (DER) encoding of the time stamp request.
>
> Although not currently used, the Content-Length directive should also be
> used in constructing the HTTP message because it helps the time stamp
> server locate where the request is within the HTTP POST.
>
> Other HTTP headers may also be present and should be ignored if they are
> not understood by the requestor or time stamp server.
>
> The time stamp request is an ASN.1 encoded message. The format of the
> request is as follows.
>
> Copy
>
> TimeStampRequest ::= SEQUENCE {
>     countersignatureType OBJECT IDENTIFIER,
>     attributes Attributes OPTIONAL,
>     content  ContentInfo
> }
>
> The countersignatureType is the /object identifier/
>
<<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms721599%28v=vs.85%">http://msdn.microsoft.com/en-us/library/windows/desktop/ms721599%28v=vs.85%
29.aspx#_security_object_identifier_gly>

> (OID) that identifies this as a time stamp countersignature and should
> be the exact OID 1.3.6.1.4.1.311.3.2.1.
>
> No attributes are currently included in the time stamp request.
>
> The content is a ContentInfo as defined by PKCS #7. The content is the
> data to be signed. For signature time stamping, the ContentType should
> be Data, and the content should be the encryptedDigest (signature) from
> the SignerInfo of the PKCS #7 content to be time stamped.
>

ContentInfo is defined in RFC2315#7   (PKCS#7) and in RFC5652#3   (CMS)
SignerInfo  is defined in RFC2315#9.2 (PKCS#7) and in RFC5652#5.3 (CMS)

>
>       Time Stamp Response
>
> The time stamp response is also sent within an HTTP 1.1 message. In the
> HTTP header, the Content-Type directive is also set to
> application/octet-stream. The body of the HTTP message is a base64
> encoding of DER encoding of the time stamp response.
>
> The time stamp response is a PKCS #7 signed message signed by the time
> stamper. The ContentInfo of the PKCS #7 message is identical to the
> ContentInfo received in the time stamp. The PKCS #7 content contains the
> signing time authenticated attribute (defined in PKCS #99, OID
> 1.2.840.113549.9.5).

This is RFC2985#5.3.3 signingTime, The OID in the MSDN spec is a
misprint, it is 1.2.840.113549.1.9.5 according to both
the RFC and my dumps of real signatures.

This is also specified in RFC5652#11.3 (CMS).

>
> After Authenticode receives the time stamp from the server, Authenticode
> incorporates the time stamp into the original PKCS #7 *SignedData*
>
<<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa387722%28v=vs.85%">http://msdn.microsoft.com/en-us/library/windows/desktop/aa387722%28v=vs.85%
29.aspx>
> as a countersignature. To accomplish this, the ContentInfo of the
> returned PKCS #7 *SignedData* is discarded, and the SignerInfo of the
> returned time stamp is copied as a countersignature into the SignerInfo
> of the original PKCS #7 *SignedData*. The certificate chain of the time
> stamper is also copied into Certificates in the original PKCS #7
> *SignedData* as an unauthenticated attribute of the original signer.
>
>

This spec matches my observations and dumps, note that counterSignature
is exactly as defined in RFC2985#5.3.6 and the MS timeStamping protocol
is designed to return a signature that can be used for this.

counterSignature is also specified in RFC5652#11.4 (CMS), however
contrary to the text of RFC5652#11.4, it is acceptable for the
counterSignature to specify a "ContentType" attribute with a value
of "data" (1.2.840.113549.1.7.1), as would be caused by the time
stamping server blindly complying with RFC5652#5.3 as its response is
technically not a counterSignature attribute until after manipulation
by the client.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp for Microsoft Authenticode?

Walter H.
In reply to this post by Jakob Bohm-7
Hi,

thanks for your infos

can you please tell me, where I can find your postings to this topic,
you made in the past?

On 19.03.2013 20:07, Jakob Bohm wrote:
> Won't work (as you saw), this function doesn't take the actual
> ContentInfo structure as input, but data which it will (mis)treat
> as an e-mail and then wrap in its own ContentInfo.  Notice how the
> messageDigest in your result is not the one in the result from the
> original RSADSI/VeriSign/Thawte/Symantec server.
>
> When the input specifies a content type of "data", you could use
> the bytes inside the inner OCTET STRING as input to cms like this
>    openssl cms -sign -binary -content filewithrawdata.bin -outform DER
how should this work, because when calling openssl like this expects
input from stdin ...
> to get something close to the right response, but this won't work
> if the request specifies a different content type.
>
> I think there was a SourceForge project related to this
>    (http://sf.net/projects/osslsigncode/)
> But I don't know its status.
>
this is a good project, but I already have signcode.exe / signtool.exe;
I want to create the timestamp server part ..., using OpenSSL

I havn't used the OpenSSL source before ...

Thanks for any help,
Walter



smime.p7s (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp for Microsoft Authenticode?

Jakob Bohm-7
(No need to CC me, I get the list e-mails in the same inbox).

You could use any of the archives of the mail lists that are mentioned
on openssl.org.

However, I think I have repeated all the stuff you didn't already
discover in
todays post, just to keep everything together in one place.

On 19-03-2013 21:41, Walter H. wrote:

> Hi,
>
> thanks for your infos
>
> can you please tell me, where I can find your postings to this topic,
> you made in the past?
>
> On 19.03.2013 20:07, Jakob Bohm wrote:
>> Won't work (as you saw), this function doesn't take the actual
>> ContentInfo structure as input, but data which it will (mis)treat
>> as an e-mail and then wrap in its own ContentInfo.  Notice how the
>> messageDigest in your result is not the one in the result from the
>> original RSADSI/VeriSign/Thawte/Symantec server.
>>
>> When the input specifies a content type of "data", you could use
>> the bytes inside the inner OCTET STRING as input to cms like this
>>    openssl cms -sign -binary -content filewithrawdata.bin -outform DER
> how should this work, because when calling openssl like this expects
> input from stdin ...
>> to get something close to the right response, but this won't work
>> if the request specifies a different content type.
>>
>> I think there was a SourceForge project related to this
>>    (http://sf.net/projects/osslsigncode/)
>> But I don't know its status.
>>
> this is a good project, but I already have signcode.exe / signtool.exe;
> I want to create the timestamp server part ..., using OpenSSL
>
> I havn't used the OpenSSL source before ...
>
> Thanks for any help,
> Walter
>
>


--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
<call:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp for Microsoft Authenticode?

Walter H.
Hello,

I got two more replies of public time stamp servers,

- msrecv01ts-asn1.text
- msrecv02ts-asn1.text (used a different source, so the hash differs)
- msrecv03ts-asn1.text

the structure of these 3 replies look nearly the same as my two generated

- myreply01cms-asn1.text
- myreply02cms-asn1.text

but with mine there is shown an error

"the connection has reached the time limit or the reply of the time
stamp service is invalid"

here is my command:

openssl cms -sign -in octet.bin -binary -out reply.der -outform DER (
-noattr ) -nosmimecap -nodetach -signer ts.crt -inkey ts.key -passin
file:ts.pass

( octet.bin is only the extracted hash of the request,
    reply.der is the output,
    ts.crt is the timestamp cert.
    ts.key is the private key of the timestamp cert.
    ts.pass is the pass phrase for the private key of the timestamp cert. )

both variants fail: with -noattr or without -noattr

what went wrong?
can someone please help me?

Thanks,
Walter


msrecv01ts-asn1.text (22K) Download Attachment
msrecv02ts-asn1.text (14K) Download Attachment
msrecv03ts-asn1.text (14K) Download Attachment
myreply01cms-asn1.text (24K) Download Attachment
myreply02cms-asn1.text (22K) Download Attachment
smime.p7s (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp for Microsoft Authenticode?

Jakob Bohm-7
On 3/22/2013 10:09 PM, Walter H. wrote:

> Hello,
>
> I got two more replies of public time stamp servers,
>
> - msrecv01ts-asn1.text
> - msrecv02ts-asn1.text (used a different source, so the hash differs)
> - msrecv03ts-asn1.text
>
> the structure of these 3 replies look nearly the same as my two generated
>
> - myreply01cms-asn1.text
This one lacks the data part, it seems to have been generated without
the "-nodetach" option.

> - myreply02cms-asn1.text
This one has the data part, but lacks the "signingTime" attribute which
is the whole point of this exercise.

>
> but with mine there is shown an error
>
> "the connection has reached the time limit or the reply of the time
> stamp service is invalid"
>
> here is my command:
>
> openssl cms -sign -in octet.bin -binary -out reply.der -outform DER (
> -noattr ) -nosmimecap -nodetach -signer ts.crt -inkey ts.key -passin
> file:ts.pass
>
> ( octet.bin is only the extracted hash of the request,
I presume you mean the data in the request, not the hash.

>     reply.der is the output,
>     ts.crt is the timestamp cert.
>     ts.key is the private key of the timestamp cert.
>     ts.pass is the pass phrase for the private key of the timestamp cert. )
>
> both variants fail: with -noattr or without -noattr
>
> what went wrong?
> can someone please help me?
>
> Thanks,
> Walter


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp for Microsoft Authenticode?

Walter H.
On 25.03.2013 18:05, Jakob Bohm wrote:
> This one lacks the data part, it seems to have been generated without
> the "-nodetach" option.
>
>> - myreply02cms-asn1.text
> This one has the data part, but lacks the "signingTime" attribute which
> is the whole point of this exercise.
>
how can I correct this?

myreply03cms-asn1.text doesn't work either, same error

Thanks,
Walter

myreply03cms-asn1.text (23K) Download Attachment
smime.p7s (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp for Microsoft Authenticode?

Raghav Varadan
In reply to this post by Walter H.
Hi,

I'm getting the following failure when trying to build FIPS capable openssl in windows:

ectest
Curve defined by Weierstrass equation
     y^2 = x^3 + a*x + b  (mod 0x17)
     a = 0x1
     b = 0x1
Point is not on curve: x = 0xD, y = 0xFFFFA41E
.\crypto\ec\ectest.c:318: ABORT
problems.....

The operating system I'm in Windows 7 and following are the steps I did:

1) ms\do_fips no-asm

2) perl Configure VC-WIN32 fips --with-fipslibdir=c:\fips\path

3) ms\do_nasm

4) ms\do_nt

5) nmake -f ms\nt.mak

6) cd out32
    ..\ms\test


The crypto test passes if do the normal build. That is changing step 2: to :perl Configure VC-WIN32

I'm kinda lost with this and thought would get some help from the user group.

Thanks

Raghav