Hello,
The following page
https://www.wolfssl.com/wolfssl-support-added-net-snmp/
announces that SNMP support is now avaialble.

Except the "follow the instructions " link  is to a repository page with a couple of diff files.  No instructions at all.

And we don't use patch/diff tools.

I am looking into adding a SNMPv3 agent to our embedded product.  While I have deciphered enough to the protocol to "be dangerous", I am looking for support writing and integrating an agent into the device running an RTOS, which already uses WolfSSL extensively.

(Off topic...  I've never seen such a kludge and poorly documented protocol in my 30+ years of network coding... requires 15+ RFCs and a PhD in some custom MIB files and how to BER them... and still no details about the protocol on the wire)

Hello,
I am writing a 802.1X handshake client and need to verify the cert chain.  If I leave the ssl_set_verify() as NULL, it fails due to a date issue, since the embedded device has no RTC.

So I need to verify that the signer for the server certificate matches the CA which I have on the client device.  And ignore if the cert date is not valid, because we can't get the time until after the 802.1X authentication occurs.

Here's my test process

• A CA where we are acting as our own Certification Authority (call it "CA1")

• A fabricated cert on the server which is signed by CA1  (call it "certificate")

• A fabricated different CA which doesn't apply to anything (call it "CA2")

(CA2 is to mimic someone attaching the device to a different 802.1X network where the server sends a cert that we don't have the correct CA for)

My goal is to ignore the errors related to the time validity, but reject if the server certificate was issued by CA "company1", while the client is using a CA from "company2"

Loading the PEM/DER data is not a problem. 
But am I loading it for the correct usage, and using the correct API calls?

I registered the callback using

SSL_set_verify(ssl, SSL_VERIFY_NONE, certVertify);

I load the CA using

SSL_user_certificate_ASN1(ssl, cabuffer, calength);

I also load the clients cert and key since the server needs peer authentication

SSL_user_certificate_ASN1(ssl, clientbuffer, clientlength);
SSL_user_certificate_ASN1(ssl, keybuffer, keylength);

If I completely ignore any errors on the client side, the 802.1X validation occurs fine, and it lets the device into the network.

But I need to be able to verify in the client that the server certificate is signed by the CA that is on the client.

The callback code is:

static int certVertify(int preverify_ok, X509_STORE_CTX *x509_ctx) {
        X509 *err_cert;
        int err, depth;
        char buf[256];
        const char *err_str;

        printf("------------------\nVerify Called\n");
        err_cert = X509_STORE_CTX_get_current_cert(x509_ctx);

        err = X509_STORE_CTX_get_error(x509_ctx);
        depth = X509_STORE_CTX_get_error_depth(x509_ctx);

        err_str = X509_verify_cert_error_string(err);
        printf("The error is: %ds  Depth: %d \n",err_str , depth);
        X509_NAME_oneline(X509_get_subject_name(err_cert), buf, sizeof(buf));
        printf("Cert is %s\n", buf);
        ...

Here's what happens and in some of these case, I don't understand what it's doing or why:
When I load the CA1 (the real one) and the time is correct, the callback gets called twice.  I am logging each time the verification callback occurs, and getting the error code, the depth, and certificate that the callback is referring to.

Error: 0  Depth: 1  Cert is CA1
Error: 0  Depth: 0  Cert is the certificate

That's fine. Makes sense.  Except we won't have the correct time in real life.

When I load the CA1 (the real one) and the time is INCORRECT, the callback gets called four times:

Error: certificate is not yet valid   Depth: 1   Cert is CA1
Error: certificate is not yet valid   Depth: 1   Cert is CA1
Error: certificate is not yet valid   Depth: 0   Cert is the certificate
Error: certificate is not yet valid   Depth: 0   Cert is the certificate

The "not yet valid makes sense", but why is it called 4 times?  Twice for each depth?

Next, when I load the CA2, which is the incorrect certification authority. This would a use where the device is attached to a network who has the incorrect CA.  And with the correct time, I get the following:

Error: Self Signed cert in chain  Depth: 1   Cert is CA1
Error: Self Signed cert in chain  Depth: 1   Cert is CA1
Error: Self Signed cert in chain  Depth: 0   Cert is the certificate

Okay, why is the callback handing me the CA from the server, and yet saying nothing about the certificate not being signed by the CA2 that I loaded?

Why is it telling me that CA1 (the actual signer of the certificate) is self signed?

Why is it calling the depth 1 twice?

Next, when I load the CA2, which is the incorrect certification authority, and the time is INCORRECT, I get the following:

Error: Self Signed cert in chain  Depth: 1   Cert is CA1
Error: certificate not yet valid    Depth: 1   Cert is CA1
Error: certificate not yet valid    Depth: 1   Cert is CA1
Error: certificate not yet valid    Depth: 0   Cert is the certificate
Error: certificate not yet valid    Depth: 0   Cert is the certificate

Now why are there 5 calls to the callback?

Any explanation about this would be greatly appreciated.

-Scott

Hello,
Here is some background:
We are using our own internal CA.  And we need a device to generate and sign a certificate using the CA.

I have all this working fine. Modeling off of OpenSSL is how I started.
However OpenSSL uses a CNF file for those settings. No such option appears to exist.

I did find this:

https://wolfssl.com/doxygen/group__ASN. … 130e2c6563

WOLFSSL_API int wc_SetDatesBuffer    (Cert *, const byte * , int )
Which is one of the more useless explainations of how to function is used I've come across.

The example code is:

 Cert myCert;
 // initialize myCert
 byte* der;
 der = (byte*)malloc(FOURK_BUF);
 // initialize der
 if(wc_SetDatesBuffer(&myCert, der, FOURK_BUF) != 0) {
     // error setting subject
 }

Which only tells me I need a DER to use as a source for the dates...  Kind of a "circular" goal... 

Functionally, this all works, except the date is bad (dec 1969 as expected)
I need to be able to control the issue date and duration.

The (simplified) steps are:

    wc_MakeRsaKey()
    ...
    wc_InitCert(&testcert);
    strcpy(testcert.subject.country, "US");
    strcpy(testcert.subject.state, "IL");
    ... //  Yeah, a request is created, all fields good, and ready to be signed...

    caCertLength = LoadCACert();    //  Load the CA from storage
    wc_SetIssuerBuffer(testcert,m_caCert, caCertLength);
     ???  
    certsize = wc_MakeCert(&testcert, dercert, 4096, &genKey, NULL, &rng);
    caKeyLength = LoadCAKey();      //  Load the private key from storage
    result = wc_RsaPrivateKeyDecode((const byte *)m_caKey, &idx, &cakey, caKeyLength);
    ????
    certsize = wc_SignCert(testcert.bodySz, testcert.sigType, dercert, 4096, &cakey, NULL, &rng);

I am suspecting somewhere after "wc_SetIssueBuffer" or just before "wc_SignCert" is where the issue date and expiration date are set.
But there are no examples or explanations.

Can someone advise?

Thanks.

Hello,
See subject line...

I am creating a certificate, and signing it with an internal CA.  All is fine.  Except I need to also include alternate subject names.

I am using 4.7

This post:
https://www.wolfssl.com/forums/topic140 … l-api.html
Does not work.
The code block

char myAltNames[] = {
                                 // SEQUENCE (2 elements)
                                 0x30, 0x14,
                                 // OBJECT IDENTIFIEER: 2.5.29.17 subjectAltName
                                 // (X.509 extension)
                                 0x06, 0x03, 0x55, 0x1D, 0x11,
                                 // OCTET STRING (1 element) 
.....

Is building the DER sequence structure for a single name.
And when this is copied in the CERT structure:

    memcpy(testcert.altNames, myAltNames, sizeof(myAltNames) );
    testcert.altNamesSz = (int) sizeof(myAltNames) ;

The cert has garbage (actually the DER OID information) in the Alternate Subject Name

                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
0...localhost   0...U...
    Signature Algorithm: sha1WithRSAEncryption
         c0:2b:4b:4d:b9:fd:1e:47:7b:0b:39:d9:17:72:6c:65:24:4e:

So the REAL solution appears to be something like

    memcpy(testcert.altNames,"DNS:LocalHost", sizeof("DNS:LocalHost") - 1);
    testcert.altNamesSz = (int) sizeof("DNS:LocalHost") - 1;

(the -1 is to remove the trailing null terminator)
Because now the certificate dump is

               Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:LocalHost.
    Signature Algorithm: sha1WithRSAEncryption
         83:bd:77:cd:3a:6a:f6:dc:ec:ab:63:cb:1c:3b:d4:39:02:4b:

Which pretty much "looks" correct, but I haven't tried it yet.

On the other hand, this doesn't work at all

    strcpy(testcert.subject.commonName, "www.whatever.com");
    strcpy(testcert.subject.email, "Info@whatever.com");
    wc_SetAltNames(&testcert, "localhost");

When I dump the generated and signed certificate, there is no X509 Extension Subject Alternative Name.

My question:
What is the correct way to set alternate names?
What is the correct way to set MULTIPLE alternate names?
What is the correct way to also set an IP address in the Subject Alternative Name field?

Short of studying the DER OID structures and mastering them (which I have done yet but I'm getting close to having to do), how can this field be set with multiple values and field types?

Scott