401 Reply by Kaleb J. Himes

(5 replies, posted in wolfSSL)

Frank42,

Thank you for sharing your solutions on the forums. Are there any outstanding items remaining or is everything working at this point?

- Kaleb

Go to forum: wolfSSL

402 Reply by Kaleb J. Himes

(10 replies, posted in wolfSSL)

Frank42,

Thanks, good catch! You are correct, I mistakenly stated the wolfssl64.sln was VS 2008 but it is in fact VS2010.

Cheers,

- Kaleb

Go to forum: wolfSSL

403 Reply by Kaleb J. Himes

(3 replies, posted in wolfSSL)

Frank,

Great questions!

So now I'm left with, how do I know which cert I need to authenitcate the server with?

You had the right approach, in fact it's usually the first one I use, I just look at the subject and issuer lines to see if they match and if they are the same name as I see if I connect to the end-point in a browser.

(1)
Once I think I've found it I load it up in our example client and try the connection. If all the signatures can be validate the client will connect. If the connection fails I know that the public key present in the root CA I think is write is not really the one that signed the cert the server is sending me.

(2)
So then I have to dig a little deeper and pay attention to the little details like the serial number. Is the Serial number on the cert I downloaded or found, the same as the one I see in the browser? That will usually take care of it but even that has failed me before due to the following:

(2.1)
Some servers are sitting behind load balancers and if ONE of those server behind the load balancer gets updated with a new cert chain you can end up receiving different cert chains from the same domain.

(2.2)
Some web clients use java script to check where you are located in the world and will re-route you to a server nearby rather than connecting to the one that would typically resolve in the DNS lookup. Since our example client makes none of those same assumptions it can end up connecting to the DNS lookup resolution rather than the one a web client would choose. These can also present different cert chains.

(2.3) There are a few other scenarios but ultimately all end with me using (3) below to figure them out.

(3)
When the above solutions fail me I resort to Wireshark and IP address. I use ping to check the IP of the domain I'm hitting from a terminal (you already had the IP so I didn't have to do that here). Once I have the IP I start Wireshark with the filer "host 67.195.228.95 in your case. I then launch our example client and once the client fails I stop wireshark. I then locate the Server Certificate packet that was send and expand it till I see the last cert send in the chain. I right-click the packet and select "Export packet bytes". I save it as some unique name and then use the openSSL command line tool to convert it to pem and check the serial number and Subject/Issuer fields.

openssl x509 -inform der -in uniquename.raw -outform pem -text > uniquename.pem

This will put human readable info at the top of the cert (like I sent yesterday).

I think that about covers it. Theres some other ticks we use but the above will solve 99% of all cases where you might have trouble tracking down the correct Root CA. Hope it helps.


Why didn't #2 in the chain work? 
i.e. It is a valid intermediate cert, but it doesn't work.

You didn't even need #2 to be loaded, the server was sending you everything you needed to validate the chain, the only missing cert was the correct Root CA.

That being said, the simple explanation is that #2 didn't sign #3, it's as simple as that. Even though it's a valid intermediate CA the public key contained within was not the same public key as the cert that originally signed #3. The serial numbers also are a give away there. The serial number of the signatory was not a matching serial number to #2.


Warm Regards,

Kaleb

Go to forum: wolfSSL

404 Reply by Kaleb J. Himes

(3 replies, posted in wolfSSL)

Hi Frank42,

I apologize for the wall of text below but here's what's happening. You are loading a Root CA that has the correct "Subject" and "Issuer" lines but the public key in that cert does not pair with cert being returned by the server. The cert you sent to me is this one:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            18:da:d1:9e:26:7d:e8:bb:4a:21:58:cd:cc:6b:3b:4a
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Validity
            Not Before: Nov  8 00:00:00 2006 GMT
            Not After : Jul 16 23:59:59 2036 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:af:24:08:08:29:7a:35:9e:60:0c:aa:e7:4b:3b:
                    4e:dc:7c:bc:3c:45:1c:bb:2b:e0:fe:29:02:f9:57:
                    08:a3:64:85:15:27:f5:f1:ad:c8:31:89:5d:22:e8:
                    2a:aa:a6:42:b3:8f:f8:b9:55:b7:b1:b7:4b:b3:fe:
                    8f:7e:07:57:ec:ef:43:db:66:62:15:61:cf:60:0d:
                    a4:d8:de:f8:e0:c3:62:08:3d:54:13:eb:49:ca:59:
                    54:85:26:e5:2b:8f:1b:9f:eb:f5:a1:91:c2:33:49:
                    d8:43:63:6a:52:4b:d2:8f:e8:70:51:4d:d1:89:69:
                    7b:c7:70:f6:b3:dc:12:74:db:7b:5d:4b:56:d3:96:
                    bf:15:77:a1:b0:f4:a2:25:f2:af:1c:92:67:18:e5:
                    f4:06:04:ef:90:b9:e4:00:e4:dd:3a:b5:19:ff:02:
                    ba:f4:3c:ee:e0:8b:eb:37:8b:ec:f4:d7:ac:f2:f6:
                    f0:3d:af:dd:75:91:33:19:1d:1c:40:cb:74:24:19:
                    21:93:d9:14:fe:ac:2a:52:c7:8f:d5:04:49:e4:8d:
                    63:47:88:3c:69:83:cb:fe:47:bd:2b:7e:4f:c5:95:
                    ae:0e:9d:d4:d1:43:c0:67:73:e3:14:08:7e:e5:3f:
                    9f:73:b8:33:0a:cf:5d:3f:34:87:96:8a:ee:53:e8:
                    25:15
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            1.3.6.1.5.5.7.1.12: 
                0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
            X509v3 Subject Key Identifier: 
                7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
    Signature Algorithm: sha1WithRSAEncryption
         93:24:4a:30:5f:62:cf:d8:1a:98:2f:3d:ea:dc:99:2d:bd:77:
         f6:a5:79:22:38:ec:c4:a7:a0:78:12:ad:62:0e:45:70:64:c5:
         e7:97:66:2d:98:09:7e:5f:af:d6:cc:28:65:f2:01:aa:08:1a:
         47:de:f9:f9:7c:92:5a:08:69:20:0d:d9:3e:6d:6e:3c:0d:6e:
         d8:e6:06:91:40:18:b9:f8:c1:ed:df:db:41:aa:e0:96:20:c9:
         cd:64:15:38:81:c9:94:ee:a2:84:29:0b:13:6f:8e:db:0c:dd:
         25:02:db:a4:8b:19:44:d2:41:7a:05:69:4a:58:4f:60:ca:7e:
         82:6a:0b:02:aa:25:17:39:b5:db:7f:e7:84:65:2a:95:8a:bd:
         86:de:5e:81:16:83:2d:10:cc:de:fd:a8:82:2a:6d:28:1f:0d:
         0b:c4:e5:e7:1a:26:19:e1:f4:11:6f:10:b5:95:fc:e7:42:05:
         32:db:ce:9d:51:5e:28:b6:9e:85:d3:5b:ef:a5:7d:45:40:72:
         8e:b7:0e:6b:0e:06:fb:33:35:48:71:b8:9d:27:8b:c4:65:5f:
         0d:86:76:9c:44:7a:f6:95:5c:f6:5d:32:08:33:a4:54:b6:18:
         3f:68:5c:f2:42:4a:85:38:54:83:5f:d1:e8:2c:f2:ac:11:d6:
         a8:ed:63:6a
-----BEGIN CERTIFICATE-----
MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2ln
biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJp
U2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y
aXR5IC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1
nmAMqudLO07cfLw8RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbex
t0uz/o9+B1fs70PbZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIz
SdhDY2pSS9KP6HBRTdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQG
BO+QueQA5N06tRn/Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+
rCpSx4/VBEnkjWNHiDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/
NIeWiu5T6CUVAgMBAAGjgbIwga8wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E
BAMCAQYwbQYIKwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAH
BgUrDgMCGgQUj+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVy
aXNpZ24uY29tL3ZzbG9nby5naWYwHQYDVR0OBBYEFH/TZafC3ey78DAJ80M5+gKv
MzEzMA0GCSqGSIb3DQEBBQUAA4IBAQCTJEowX2LP2BqYLz3q3JktvXf2pXkiOOzE
p6B4Eq1iDkVwZMXnl2YtmAl+X6/WzChl8gGqCBpH3vn5fJJaCGkgDdk+bW48DW7Y
5gaRQBi5+MHt39tBquCWIMnNZBU4gcmU7qKEKQsTb47bDN0lAtukixlE0kF6BWlK
WE9gyn6CagsCqiUXObXbf+eEZSqVir2G3l6BFoMtEMze/aiCKm0oHw0LxOXnGiYZ
4fQRbxC1lfznQgUy286dUV4otp6F01vvpX1FQHKOtw5rDgb7MzVIcbidJ4vEZV8N
hnacRHr2lVz2XTIIM6RUthg/aFzyQkqFOFSDX9HoLPKsEdao7WNq
-----END CERTIFICATE-----

The Cert that the server is sending is this one:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Validity
            Not Before: Nov  8 00:00:00 2006 GMT
            Not After : Nov  7 23:59:59 2021 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:af:24:08:08:29:7a:35:9e:60:0c:aa:e7:4b:3b:
                    4e:dc:7c:bc:3c:45:1c:bb:2b:e0:fe:29:02:f9:57:
                    08:a3:64:85:15:27:f5:f1:ad:c8:31:89:5d:22:e8:
                    2a:aa:a6:42:b3:8f:f8:b9:55:b7:b1:b7:4b:b3:fe:
                    8f:7e:07:57:ec:ef:43:db:66:62:15:61:cf:60:0d:
                    a4:d8:de:f8:e0:c3:62:08:3d:54:13:eb:49:ca:59:
                    54:85:26:e5:2b:8f:1b:9f:eb:f5:a1:91:c2:33:49:
                    d8:43:63:6a:52:4b:d2:8f:e8:70:51:4d:d1:89:69:
                    7b:c7:70:f6:b3:dc:12:74:db:7b:5d:4b:56:d3:96:
                    bf:15:77:a1:b0:f4:a2:25:f2:af:1c:92:67:18:e5:
                    f4:06:04:ef:90:b9:e4:00:e4:dd:3a:b5:19:ff:02:
                    ba:f4:3c:ee:e0:8b:eb:37:8b:ec:f4:d7:ac:f2:f6:
                    f0:3d:af:dd:75:91:33:19:1d:1c:40:cb:74:24:19:
                    21:93:d9:14:fe:ac:2a:52:c7:8f:d5:04:49:e4:8d:
                    63:47:88:3c:69:83:cb:fe:47:bd:2b:7e:4f:c5:95:
                    ae:0e:9d:d4:d1:43:c0:67:73:e3:14:08:7e:e5:3f:
                    9f:73:b8:33:0a:cf:5d:3f:34:87:96:8a:ee:53:e8:
                    25:15
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.verisign.com/pca3.crl

            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Certificate Policies: 
                Policy: X509v3 Any Policy
                  CPS: https://www.verisign.com/cps

            X509v3 Subject Key Identifier: 
                7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
            1.3.6.1.5.5.7.1.12: 
                0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
            Authority Information Access: 
                OCSP - URI:http://ocsp.verisign.com

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing, Netscape Server Gated Crypto, 2.16.840.1.113733.1.8.1
    Signature Algorithm: sha1WithRSAEncryption
         13:02:dd:f8:e8:86:00:f2:5a:f8:f8:20:0c:59:88:62:07:ce:
         ce:f7:4e:f9:bb:59:a1:98:e5:e1:38:dd:4e:bc:66:18:d3:ad:
         eb:18:f2:0d:c9:6d:3e:4a:94:20:c3:3c:ba:bd:65:54:c6:af:
         44:b3:10:ad:2c:6b:3e:ab:d7:07:b6:b8:81:63:c5:f9:5e:2e:
         e5:2a:67:ce:cd:33:0c:2a:d7:89:56:03:23:1f:b3:be:e8:3a:
         08:59:b4:ec:45:35:f7:8a:5b:ff:66:cf:50:af:c6:6d:57:8d:
         19:78:b7:b9:a2:d1:57:ea:1f:9a:4b:af:ba:c9:8e:12:7e:c6:
         bd:ff
-----BEGIN CERTIFICATE-----
MIIE0DCCBDmgAwIBAgIQJQzo4DBhLp8rifcFTXz4/TANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDYxMTA4MDAwMDAwWhcNMjExMTA3MjM1OTU5WjCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1nmAMqudLO07cfLw8
RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbext0uz/o9+B1fs70Pb
ZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIzSdhDY2pSS9KP6HBR
TdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQGBO+QueQA5N06tRn/
Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+rCpSx4/VBEnkjWNH
iDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/NIeWiu5T6CUVAgMB
AAGjggGbMIIBlzAPBgNVHRMBAf8EBTADAQH/MDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA4GA1UdDwEB/wQEAwIBBjA9
BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL2NwczAdBgNVHQ4EFgQUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwbQYI
KwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQU
j+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVyaXNpZ24uY29t
L3ZzbG9nby5naWYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC52ZXJpc2lnbi5jb20wPgYDVR0lBDcwNQYIKwYBBQUHAwEGCCsGAQUFBwMC
BggrBgEFBQcDAwYJYIZIAYb4QgQBBgpghkgBhvhFAQgBMA0GCSqGSIb3DQEBBQUA
A4GBABMC3fjohgDyWvj4IAxZiGIHzs73Tvm7WaGY5eE43U68ZhjTresY8g3JbT5K
lCDDPLq9ZVTGr0SzEK0saz6r1we2uIFjxfleLuUqZ87NMwwq14lWAyMfs77oOghZ
tOxFNfeKW/9mz1Cvxm1XjRl4t7mi0VfqH5pLr7rJjhJ+xr3/
-----END CERTIFICATE-----

Please run your test with this Root CA and let me know your results!

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
    Signature Algorithm: md2WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Validity
            Not Before: Jan 29 00:00:00 1996 GMT
            Not After : Aug  1 23:59:59 2028 GMT
        Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:c9:5c:59:9e:f2:1b:8a:01:14:b4:10:df:04:40:
                    db:e3:57:af:6a:45:40:8f:84:0c:0b:d1:33:d9:d9:
                    11:cf:ee:02:58:1f:25:f7:2a:a8:44:05:aa:ec:03:
                    1f:78:7f:9e:93:b9:9a:00:aa:23:7d:d6:ac:85:a2:
                    63:45:c7:72:27:cc:f4:4c:c6:75:71:d2:39:ef:4f:
                    42:f0:75:df:0a:90:c6:8e:20:6f:98:0f:f8:ac:23:
                    5f:70:29:36:a4:c9:86:e7:b1:9a:20:cb:53:a5:85:
                    e7:3d:be:7d:9a:fe:24:45:33:dc:76:15:ed:0f:a2:
                    71:64:4c:65:2e:81:68:45:a7
                Exponent: 65537 (0x10001)
    Signature Algorithm: md2WithRSAEncryption
         bb:4c:12:2b:cf:2c:26:00:4f:14:13:dd:a6:fb:fc:0a:11:84:
         8c:f3:28:1c:67:92:2f:7c:b6:c5:fa:df:f0:e8:95:bc:1d:8f:
         6c:2c:a8:51:cc:73:d8:a4:c0:53:f0:4e:d6:26:c0:76:01:57:
         81:92:5e:21:f1:d1:b1:ff:e7:d0:21:58:cd:69:17:e3:44:1c:
         9c:19:44:39:89:5c:dc:9c:00:0f:56:8d:02:99:ed:a2:90:45:
         4c:e4:bb:10:a4:3d:f0:32:03:0e:f1:ce:f8:e8:c9:51:8c:e6:
         62:9f:e6:9f:c0:7d:b7:72:9c:c9:36:3a:6b:9f:4e:a8:ff:64:
         0d:64
-----BEGIN CERTIFICATE-----
MIICPDCCAaUCEHC65B0Q2Sk0tjjKewPMur8wDQYJKoZIhvcNAQECBQAwXzELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz
cyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2
MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVowXzELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAzIFB1YmxpYyBQcmlt
YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDJXFme8huKARS0EN8EQNvjV69qRUCPhAwL0TPZ2RHP7gJYHyX3KqhE
BarsAx94f56TuZoAqiN91qyFomNFx3InzPRMxnVx0jnvT0Lwdd8KkMaOIG+YD/is
I19wKTakyYbnsZogy1Olhec9vn2a/iRFM9x2Fe0PonFkTGUugWhFpwIDAQABMA0G
CSqGSIb3DQEBAgUAA4GBALtMEivPLCYATxQT3ab7/AoRhIzzKBxnki98tsX63/Do
lbwdj2wsqFHMc9ikwFPwTtYmwHYBV4GSXiHx0bH/59AhWM1pF+NEHJwZRDmJXNyc
AA9WjQKZ7aKQRUzkuxCkPfAyAw7xzvjoyVGM5mKf5p/AfbdynMk2OmufTqj/ZA1k
-----END CERTIFICATE-----

Warm Regards,

Kaleb

Go to forum: wolfSSL

405 Reply by Kaleb J. Himes

(1 replies, posted in wolfSSL)

Hi Nikhil.Dosi,

Were both the key structure and the RNG initialized prior to calling wc_MakeRsaKey? Please find a code sample below for setup:

        #define HEAP_HINT NULL
        #define WC_RSA_EXPONENT 65537

         WC_RNG rng;
         int keySz = 2048;
         RsaKey genKey; 

         ret = wc_InitRng(&rng); 
         /* check ret val is 0 */
 #ifdef WC_RSA_BLINDING                                                                                                             
         ret = wc_RsaSetRNG(&key, &rng);                                          
        /* check ret is not less than 0 */                                                                                                                                               
 #endif

         ret = wc_InitRsaKey(&genKey, HEAP_HINT);                                 
         /* check ret val is 0 */                                                                      
         ret = wc_MakeRsaKey(&genKey, keySz, WC_RSA_EXPONENT, &rng);              
         /* check ret val is 0 */

Is this the flow of your program? If not could you sent the code you are getting the odd return value from so we can check it on our end or better yet reproduce the issue?

Warm Regards,

Kaleb

Go to forum: wolfSSL

406 Reply by Kaleb J. Himes

(6 replies, posted in wolfSSL)

Bob,

It's my pleasure, glad we were able to be of assistance here.
Let us know if anything else comes up.

Warm Regards,

Kaleb

Go to forum: wolfSSL

407 Reply by Kaleb J. Himes

(6 replies, posted in wolfSSL)

Hi Bob,

If you just downloaded the source that tells me you are more than likely working with 3.14.0 but the issue is not affecting you with your current settings so that is good, no need to get me the version. I have already taken action to address the issue I found anyway.

Very happy to hear the cert worked for you. It's pretty simple to determine a root CA once you know what to look for. Are you familiar with the OpenSSL command line utility?

If you download a cert in DER format you can easily convert it to PEM with this command from a terminal:

openssl x509 -inform der -in cert.crt -outform pem -text > cert.pem

Or if you download a PEM formatted cert just do:

openssl x509 -inform PEM -in cert.pem -outform pem -text > cert-human.pem

The "-text" option tells openSSL to put human-readable information at the top of the PEM.

That human-readable information is where you track down the CA from. The first few lines will always be something like this:

  1 Certificate:                                                                     
  2     Data:                                                                        
  3         Version: 3 (0x2)                                                         
  4         Serial Number: 0 (0x0)                                                   
  5     Signature Algorithm: sha1WithRSAEncryption                                   
  6         Issuer: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority
  7         Validity                                                                 
  8             Not Before: Jun 29 17:06:20 2004 GMT                                 
  9             Not After : Jun 29 17:06:20 2034 GMT                                 
 10         Subject: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority

The lines I pay attention to in a case like yours are line 6 and line 10 in the above. The lines that specify the "Issuer" and the "Subject". You had all the right steps for finding the certs but what might not be so obvious is that a server is NOT required to send it's root CA since a client has to have a copy of that loaded anyway in order to verify the server. It's just extra memory the client has to allocate to receive it and then ends up with two copies of the same thing.

So if you connect to a server and get the top-most cert in the chain it sends just convert it using the OpenSSL command line tool and check the Subject and Issuer lines. If they are identical then you know you have a copy of the Root CA. If they are not identical then look at what is in the "Issuer" line. That is the cert that "Issued" the current cert you are looking at. Track that cert down and repeat the process until you find the top-level cert where the Issuer and Subject lines match. That is the true ROOT CA. Anything else is just an intermediate CA or an entity cert.

The server in question is a perfect example because the top-most cert in the chain that IT sent was: "VeriSign Class 3 Public Primary Certification Authority - G5" When I check the Subject Issuer lines for that cert I got:

  1 Certificate:                                                                     
  2     Data:                                                                        
  3         Version: 3 (0x2)                                                         
  4         Serial Number:                                                           
  5             25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd                      
  6     Signature Algorithm: sha1WithRSAEncryption                                   
  7         Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
  8         Validity                                                                 
  9             Not Before: Nov  8 00:00:00 2006 GMT                                 
 10             Not After : Nov  7 23:59:59 2021 GMT                                 
 11         Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized     use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5

We can see in the above that line 7 and line 11 are NOT identical.
So since the issuer was "Class 3 Public Primary Certification Authority" I tracked that cert down and checked it. The result was:

  1 Certificate:                                                                     
  2     Data:                                                                        
  3         Version: 1 (0x0)                                                         
  4         Serial Number:                                                           
  5             70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf                      
  6     Signature Algorithm: md2WithRSAEncryption                                    
  7         Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
  8         Validity                                                                 
  9             Not Before: Jan 29 00:00:00 1996 GMT                                 
 10             Not After : Aug  1 23:59:59 2028 GMT                                 
 11         Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority

Since the Subject and Issuers match I now know I have found the True Root CA. That is the cert I sent you.

Cheers,

Kaleb

Go to forum: wolfSSL

408 Reply by Kaleb J. Himes

(6 replies, posted in wolfSSL)

Hi bob.carleone,

OK so I was able to connect to that server with this certificate loaded in "wolfSSL_CTX_load_verify_buffer", could you try it out and let me know your results:

-----BEGIN CERTIFICATE-----
MIICPDCCAaUCEHC65B0Q2Sk0tjjKewPMur8wDQYJKoZIhvcNAQECBQAwXzELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz
cyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2
MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVowXzELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAzIFB1YmxpYyBQcmlt
YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDJXFme8huKARS0EN8EQNvjV69qRUCPhAwL0TPZ2RHP7gJYHyX3KqhE
BarsAx94f56TuZoAqiN91qyFomNFx3InzPRMxnVx0jnvT0Lwdd8KkMaOIG+YD/is
I19wKTakyYbnsZogy1Olhec9vn2a/iRFM9x2Fe0PonFkTGUugWhFpwIDAQABMA0G
CSqGSIb3DQEBAgUAA4GBALtMEivPLCYATxQT3ab7/AoRhIzzKBxnki98tsX63/Do
lbwdj2wsqFHMc9ikwFPwTtYmwHYBV4GSXiHx0bH/59AhWM1pF+NEHJwZRDmJXNyc
AA9WjQKZ7aKQRUzkuxCkPfAyAw7xzvjoyVGM5mKf5p/AfbdynMk2OmufTqj/ZA1k
-----END CERTIFICATE-----

Also could you tell me which version of wolfSSL you are working with? I ask because I tracked down the malformed buffer error I was getting the other day and it looks like we added some logic that may impact connecting to that server in our latest release. I want to make sure you have a release without this logic.

Warm Regards,

Kaleb

Go to forum: wolfSSL

409 Reply by Kaleb J. Himes

(6 replies, posted in wolfSSL)

Hi bob.carleone,

Great question! I did a quick check as I just suspected the wrong CA was being used, curiously though I keep getting a "Malformed buffer error" on the "server hello" message coming back from that server. It's the end of my work day unfortunately so I will get back on this first thing in the morning and let you know what I find. Thank you for your question!


Cheers,

Kaleb

Go to forum: wolfSSL

410 Reply by Kaleb J. Himes

(5 replies, posted in wolfSSL)

Hi Frank42,

Since you are working with WEC6 could you try defining "_WIN32_WCE" in the project properties->C/C++->Preprocessor

This define should instead include <windows.h> if you look at our header <wolfssl-root>/wolfssl/wolfcrypt/wc_port.h and look at our checks for _WIN32_WCE.

Let us know if this resolves the issues you are seeing.

Warm Regards,

Kaleb

Go to forum: wolfSSL

411 Reply by Kaleb J. Himes

(10 replies, posted in wolfSSL)

Josef,

There should be checks for the define _WIN32_WCE in the following headers and source files:

<wolfssl-root>/wolfssl/internal.h
<wolfssl-root>/wolfssl/wolfcrypt/wc_port.h

<wolfssl-root>/wolfcrypt/src/wc_port.c
<wolfssl-root>/src/wolfio.c

If you are not seeing those defines could you tell me which version of the wolfssl library you are working with by checking <wolfssl-root>/wolfssl/version.h?

For example in <wolfssl-root>/wolfcrypt/src/wc_port.c:

1227 #ifndef NO_ASN_TIME                                                              
1228 #if defined(_WIN32_WCE)                                                          
1229 time_t windows_time(time_t* timer)                                               
1230 {                                                                                
1231     SYSTEMTIME     sysTime;                                                      
1232     FILETIME       fTime;                                                        
1233     ULARGE_INTEGER intTime;                                                      
1234     time_t         localTime;                                                    
1235                                                                                  
1236     if (timer == NULL)                                                           
1237         timer = &localTime;                                                      
1238                                                                                  
1239     GetSystemTime(&sysTime);                                                     
1240     SystemTimeToFileTime(&sysTime, &fTime);                                      
1241                                                                                  
1242     XMEMCPY(&intTime, &fTime, sizeof(FILETIME));                                 
1243     /* subtract EPOCH */                                                         
1244     intTime.QuadPart -= 0x19db1ded53e8000;                                       
1245     /* to secs */                                                                
1246     intTime.QuadPart /= 10000000;                                                
1247     *timer = (time_t)intTime.QuadPart;                                           
1248                                                                                  
1249     return *timer;                                                               
1250 }                                                                                
1251 #endif /*  _WIN32_WCE */ 
....

Warm Regards,

Kaleb

Go to forum: wolfSSL

412 Reply by Kaleb J. Himes

(10 replies, posted in wolfSSL)

Hi Josef,

Did you try updating the pre-processor macros to include the define "_WIN32_WCE "?

I apologize I do not have a test environment with VS 2008 setup. I can ask around to see if one of our other engineers has a setup to test this out but I can't make any promises as it is a product you can no longer download from Microsoft for testing purposes.

Warm Regards,

Kaleb

Go to forum: wolfSSL

413 Reply by Kaleb J. Himes

(10 replies, posted in wolfSSL)

Hi Josef,

In the wolfSSL root directory you will find a solution file called "wolfssl64.sln". By default this is set for VS 2008.

Let us know if you have any issues working with it. We also have a guide here that you may find useful: https://www.wolfssl.com/docs/visual-studio/

Warm Regards,

Kaleb

Go to forum: wolfSSL

414 Reply by Kaleb J. Himes

(1 replies, posted in wolfSSL)

Hi jl,

Thank you for the question. I'll check with the team to see if anyone has this on their TODO list and let you know what I find.

Cheers,

Kaleb

Go to forum: wolfSSL

415 Reply by Kaleb J. Himes

(1 replies, posted in wolfSSL)

Hi jl,

Thank you for using the wolfSSL forums, it looks like you just have the algorithm specs backwards IE:

aes-128-cbc

VS. 

aes-cbc-128

try:

wolfssl -encrypt -h

to output a usage example:

kalebhimes$ wolfssl -encrypt -h

Available En/De crypt Algorithms with current configure settings.

aes-cbc-128        aes-cbc-192        aes-cbc-256
aes-ctr-128        aes-ctr-192        aes-ctr-256
3des-cbc-56        3des-cbc-112        3des-cbc-168
camellia-cbc-128    camellia-cbc-192    camellia-cbc-256

***************************************************************

ENCRYPT USAGE: wolfssl -encrypt <-algorithm> -in <filename> -pwd <password> -out <output file name>

***************************************************************

EXAMPLE: 

wolfssl -encrypt aes-cbc-128 -pwd Thi$i$myPa$$w0rd -in somefile.txt -out encryptedfile.txt

Warmest Regards,

Kaleb

Go to forum: wolfSSL

416 Reply by Kaleb J. Himes

(5 replies, posted in wolfSSL)

Hi v.swathi,

You did say that you were only sending part of the client and server code but just to make sure are you actually opening a TCP socket before calling wolfSSL_connect or wolfSSL_accept? The errors you noted would actually occur if no socket were opened (there are other cases to) but the first thing to check is if the sockets are actually opened.

Example from the server side pulled from: https://github.com/wolfSSL/wolfssl-exam … rver-tls.c

#define DEFAULT_PORT 11111

...

    /* Create a socket that uses an internet IPv4 address,
     * Sets the socket to be stream based (TCP),
     * 0 means choose the default protocol. */
    if ((client = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
        fprintf(stderr, "ERROR: failed to create the socket\n");
        return -1;
    }

    /* Initialize the server address struct with zeros */
    memset(&servAddr, 0, sizeof(servAddr));

    /* Fill in the server address */
    servAddr.sin_family      = AF_INET;             /* using IPv4      */
    servAddr.sin_port        = htons(DEFAULT_PORT); /* on DEFAULT_PORT */
    servAddr.sin_addr.s_addr = INADDR_ANY;          /* from anywhere   */



    /* Bind the server socket to our port */
    if (bind(client, (struct sockaddr*)&servAddr, sizeof(servAddr)) == -1) {
        fprintf(stderr, "ERROR: failed to bind\n");
        return -1;
    }

    /* Listen for a new connection, allow 5 pending connections */
    if (listen(client, 5) == -1) {
        fprintf(stderr, "ERROR: failed to listen\n");
        return -1;
    }

See how this would also be done on the client side: https://github.com/wolfSSL/wolfssl-exam … ient-tls.c

Regards,

Kaleb

Go to forum: wolfSSL

417 Reply by Kaleb J. Himes

(5 replies, posted in wolfSSL)

Hi cxnb,

You should never manually define a cipher suite like:

#define BUILD_TLS_RSA_WITH_AES_256_CBC_SHA
#define BUILD_TLS_RSA_WITH_AES_128_CBC_SHA

Instead you would control enabling that through the defines that CONTROL that (See <wolfssl-root>/wolfssl/internal.h for reference below:

 277     #if !defined(NO_RSA) && !defined(NO_AES) && !defined(NO_TLS)
 278         #if !defined(NO_SHA)
 279             #if defined(WOLFSSL_STATIC_RSA)
 280                 #ifdef WOLFSSL_AES_128
 281                     #define BUILD_TLS_RSA_WITH_AES_128_CBC_SHA
 282                 #endif
 283                 #ifdef WOLFSSL_AES_256
 284                     #define BUILD_TLS_RSA_WITH_AES_256_CBC_SHA
 285                 #endif
 286             #endif
 287             #if defined(HAVE_NTRU) && defined(WOLFSSL_STATIC_RSA)
 288                 #ifdef WOLFSSL_AES_128
 289                     #define BUILD_TLS_NTRU_RSA_WITH_AES_128_CBC_SHA
 290                 #endif
 291                 #ifdef WOLFSSL_AES_256
 292                     #define BUILD_TLS_NTRU_RSA_WITH_AES_256_CBC_SHA
 293                 #endif
 294             #endif
 295         #endif

So the defines to control that cipher suite are:

// do NOT define this: #define NO_RSA
// do NOT define this: #define NO_AES
// do NOT define this: #define NO_TLS
// do NOT define this: #define NO_SHA
#define WOLFSSL_STATIC_RSA // do define this

// automatically enabled if not defined NO_AES, no need to manually define: WOLFSSL_AES_256

So basically you just need to define WOLFSSL_STATIC_RSA to turn on both of those cipher suites, but never define it manually like you did as that could cause undefined behavior or send a "false" list of supported cipher suites to the server.

My successful tests used ECDHE, we do not recommend using WOLFSSL_STATIC_RSA as those do not provide perfect forward secrecy. Could you try adding the define HAVE_ECC and let me know your results?


Warm Regards,

Kaleb

Go to forum: wolfSSL

418 Reply by Kaleb J. Himes

(5 replies, posted in wolfSSL)

Hi cxnb,

Thank you for contacting wolfSSL via the forums and for your interest. To do a quick test I opened a terminal on my Mac and ran these commands:


cd ~/wolfssl-3.13.0
./configure && make

./examples/client/client -h rapidssl.com -p 443 -d -g
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSL curve name is SECP521R1
SSL connect ok, sending GET...
HTTP/1.1 301 Moved Permanently
Date: Wed, 07 Mar 2018 00:01:06 GMT
Server: Ap
ache
Strict-Transport-Security: max-age=15768000
X-Frame-Options: SAMEORIGIN


./examples/client/client -h comodo.com -p 443 -d -g
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
SSL connect ok, sending GET...
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Wed, 07 Mar 2018 00:01:27 
GMT
Content-Type: text/html
Connection: close
Location: [url]http://www.comodo.co[/url]

the -d option just disables peer checking temporarily so I didn't have to track down the CA certificates for those sites to connect to them.

It looks like both connections worked just fine. I tested also against the IP 69.58.181.103 for rapidssl.com and www-rapidssl-ilg.verisign.net

All tests were successful. Could you tell me how you have wolfSSL configured? Which cipher suites are currently enabled? Perhaps  those server only support specific cipher suites that need to be enabled when you build our library before you can connect.

Warm Regards,

Kaleb

Go to forum: wolfSSL

419 Reply by Kaleb J. Himes

(1 replies, posted in wolfSSL)

Hi Miguel,

Have you tried visiting that domain in a standard browser? Browsers can't resolve it, I've done some digging and very oddly I can ping that domain but it will never send a certificate back regardless of what cipher suite I try to use. Seems like an implementation bug on the server end.

Warm Regards,

Kaleb

(See attached zip for wireshark traces)

Go to forum: wolfSSL

420 Reply by Kaleb J. Himes

(10 replies, posted in wolfSSL)

Hi Bitgid and amirmaim,

Summary:

Some TLS servers may present an incomplete certificate chain. For example they may include an additional certificate for validating signed mail messgaes. By default wolfSSL validates all certificates in the provided chain. This differs from other TLS engines, such as openssl, which allow any valid chain for the server certificate.

We consider it best practice to validate all certificates in the chain and use this by default. If you are not able to load CA's for all certificates in the chain or want to allow alternate certificate chains then you can enable support for it using  `#define WOLFSSL_ALT_CERT_CHAINS` or with `./configure CFLAGS="-DWOLFSSL_ALT_CERT_CHAINS`.

Let us know if you have any other questions, concerns, comments on this topic.

Warm Regards,

Kaleb

Go to forum: wolfSSL

421 Reply by Kaleb J. Himes

(4 replies, posted in wolfCrypt)

Hi ppommarel,

Just as a note here you had wc_PrivateKeyDecrypt so I assumed you meant wc_PrivateKeyDecode and sent you a relevant example. I did want to check though, is it possible you may have meant wc_PrivateDecrypt instead? If that is the case then you may not have called:

 #ifdef WC_RSA_BLINDING
         ret = wc_RsaSetRNG(&key, &rng);
         if (ret < 0) {
             // ERROR OUT CASE
         }
 #endif

This could also cause that error to occur.


Warm Regards,

Kaleb

Go to forum: wolfCrypt

422 Reply by Kaleb J. Himes

(4 replies, posted in wolfCrypt)

Hi ppommarel,

Thank you for your questions and interest in wolfSSL. Sorry for the delay.

I have coded up an example here that will perform the same steps as openssl sign op (Not sure if you are doing signatures or otherwise) but this example shows the flow and how to initialize the RNG for calling wc_PrivateKeyDecode.

Let us know if you continue to have any issues and for much faster response time please shoot an email to support@wolfssl.com anytime.

/* To compile:
 *
 * gcc -Wall main.c -lwolfssl
 *
 */

#include <stdio.h>
#include <stdlib.h>

#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/rsa.h>
#include <wolfssl/ssl.h>
#include <wolfssl/wolfcrypt/rsa.h>
#include <wolfssl/wolfcrypt/asn.h>
#include <wolfssl/wolfcrypt/coding.h>
#include <wolfssl/wolfcrypt/sha256.h>

static void err_sys(const char* msg, int ret)
{
    if (ret) {
        printf("ERROR: %s, ret = %d\n", msg, ret);
    } else {
        printf("ERROR: %s\n", msg);
    }
    exit(EXIT_FAILURE);
}

int main(void)
{
    int  ret;
    int  derKeySz;
    byte derKey[4096];

    FILE*  file;
    RNG    rng;
    RsaKey privKey;
    word32 idx = 0;

    Sha256  sha;
    byte hash[SHA256_DIGEST_SIZE];
    byte sig[1024];

    int  inSz;
    byte in[1024];
    int encodedSz;
    byte encoded[1024];
    byte base64[1024];
    word32 base64Len = sizeof(base64);

    file = fopen("./input.txt", "rb");
    if (!file)
        err_sys("failed to open input.txt", 0);

    inSz = fread(in, 1, sizeof(in), file);
    fclose(file);

    /* init RNG */
    ret = wc_InitRng(&rng);
    if (ret != 0)
        err_sys("wc_InitRng failed", ret);

    /* import DER-encoded private key into RsaKey structure */
    file = fopen("./key.der", "rb");
    if (!file)
        err_sys("can't open key file", 0);

    derKeySz = fread(derKey, 1, sizeof(derKey), file);
    fclose(file);

    wc_InitRsaKey(&privKey, 0);
    ret = wc_RsaPrivateKeyDecode(derKey, &idx, &privKey, derKeySz);
    if (ret != 0)
        err_sys("wc_RsaPrivateKeyDecode failed", ret);

    /* hash data */
    wc_InitSha256(&sha);
    wc_Sha256Update(&sha, in, inSz);
    wc_Sha256Final(&sha, hash);

    /* write hash to "hash-wolfssl" file */
    file = fopen("./hash-wolfssl", "wb");
    if (!file)
        err_sys("failed to open hash-wolfssl file", 0);

    ret = (int)fwrite(hash, 1, SHA256_DIGEST_SIZE, file);
    fclose(file);

    /* Encode the signature before signing */
    encodedSz = wc_EncodeSignature(encoded, hash, SHA256_DIGEST_SIZE, SHA256h);
    if (ret < 0)
        err_sys("failed to encode signature", ret);

    /* sign hash */
    ret = wc_RsaSSL_Sign(encoded, encodedSz, sig, sizeof(sig), &privKey,
                                                                         &rng);
    if (ret < 0)
        err_sys("wc_RsaSSL_Sign failed", ret);

     ret = Base64_Encode(sig, ret, base64, &base64Len);                  
     if (ret != 0)                                                               
         printf("ERROR %d\n", ret);

    /* write signature to "signature-wolfssl" file */
    file = fopen("./signature-wolfssl", "wb");
    if (!file)
        err_sys("failed to open signature-wolfssl file", 0);

    ret = (int)fwrite(base64, 1, base64Len, file);
    fclose(file);

    return 0;
}

Warm Regards,

Kaleb

Go to forum: wolfCrypt

423 Reply by Kaleb J. Himes

(1 replies, posted in wolfSSL)

Hi lum,

Could you tell me a little about the project you are working on and interest in uTasker 1.4 support? In the meantime I will check with our team here at wolfSSL and see if we have any developers that have worked or been working on uTasker recently.


Warmest Regards,

Kaleb

Go to forum: wolfSSL

424 Reply by Kaleb J. Himes

(1 replies, posted in wolfSSL)

Hi Yolojohn,

#define close(s) closesocket(s)

The only time that define should occur is when USE_WINDOWS_API is defined and that is the correct API call for the .NET framework. Are you working on windows but not using the windows c++ standard library which implements closesocket?

Could you tell us a little more about your build environment and setup, what your end goals are for the project etc so we can provide a good solution to this issue?

As for the crash it looks like you have not included the same settings as used to build the library (I only see hmac.h being included).

Our default examples use the header <wolfssl-root>/IDE/WIN/user_settings.h to control the setup of our library and in the project we add the include path C:\path-to\<wolfssl-root>/IDE/WIN and the pre-processor macro "WOLFSSL_USER_SETTINGS" so that the <wolfssl-root>/wolfcrypt/settings/settings.h will pull in the user_settings automatically. All the same pre-processor macros set in the wolfssl-library project and any customer user_settings.h should also be included in the application. A mismatch in settings will very often cause crashes of the nature you reported.

Warm Regards,


Kaleb

Go to forum: wolfSSL

425 Reply by Kaleb J. Himes

(2 replies, posted in wolfCrypt)

michymd,

We got a chance to read through parts of the research you sent and from what we can tell this research applied to the underling math library (libgcrypt). wolfSSL does not use this math library, our math was based off ref10 which has built-in timing resistance for curve25519.

Looking forward to details of your research and interest!

Warm Regards,

Kaleb

Go to forum: wolfCrypt