Hello,

See subject line.
I am trying to create and sign a certificate on the fly.  I've gone through the examples (some with bugs), dug through API doc, debugged over and over... and managed to piece together this sequence.

The code, and a dummy CA cert/key are attached.

The code below simply does (or is supposed to)

• [1]Create a 2048 key pair
  [2]Convert it to DER
  [3]Then convert it to PEM
  [4]Save the private key.pem
  [5]Create a Cert
  [6]Load a CA
  [7]Set the issuer
  [8]Make the cert
  [9]Load the CA Key
  [10]Decode the CA key
  [11]Sign the Cert
  [12]Convert the Cert to PEM
  [13]Save the Cert.pem

It gives a corrupted PEM file.

I've gone as far as creating a self signed and it works.  Adding the steps to load the CA, set issuer, signed it are creating the bad PEM.  I can't remove any of those individual steps to see what is breaking.

This is a Windows based build as a first development concept.
Since this will ultimately be embedded without a file system, the code loads the ca/key and runs from memory buffers.

The last half of the PEM is simply uninitialized memory.

-----BEGIN CERTIFICATE-----
MIICeKADAgECAhAIA+FO9NCldJWF6ua77BzkMA0GCSqGSIb3DQEBBQUAMHsxCzAJ
BgNVBAYTAlhYMQswCQYDVQQIDAJYWDEQMA4GA1UEBwwHQW55Q2l0eTENMAsGA1UE
CgwERGVtbzENMAsGA1UECwwERGVtbzERMA8GA1UEAwwIZGVtby5jb20xHDAaBgkq
hkiG9w0BCQEWDWluZm9ARGVtby5jb20wIhgPMjAyMTA2MDMxMzAxMzVaGA8yMDIy
MTAxNzEzMDEzNVowgYgxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJaWjESMBAGA1UE
BwwJVGhpcyBDaXR5MQ0wCwYDVQQKDARZYWRhMQwwCgYDVQQLDANEZXYxGTAXBgNV
BAMMEHd3dy53aGF0ZXZlci5jb20xIDAeBgkqhkiG9w0BCQEWEUluZm9Ad2hhdGV2
ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ilzmeb9p6h0
fB5uNXkxNbuFvPP3lXVoOqM9wpz+yD/I/tL7EmWjgGkrjC0EBFPp6GwGbeWMR8Ui
4nQNTSYuCSJXUv/W/q4pvyEcx4CM+Of5GxUNRnDrQeVbHoiWfum2TGqPngzJVGiO
7ji6j3xlGUqQowS3CNQVAmKcXdVXaWJWyFfzbl5AjBlRjUgX08YsXc1bP7Wg291Z
88U7aY2skIgv1TJiftZrlxvPHa+uRMql5OS6cQkQ2psXRvEHurvwkij4MMUJaoCs
0uRmX8qDy1tXX/GwN6kGFcuoPJwNH7tP3adTFFrmWeevLL5n1xZmWovor15CxpXC
BsxPwKdclwIDAQABzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM
zMzMzMzMzMzMzMzMzMzMzMzMzMw=
-----END CERTIFICATE-----

This is the code being used.  ALL the return codes are good (even though they are not tested, they are good as I step through with the debugger)

#include <stdio.h>

#include "wolfssl\ssl.h"
#include "wolfssl/wolfcrypt\asn_public.h"    /*  Used for cert generation */
#include "wolfssl/wolfcrypt/rsa.h"        /*  Used for RNG and RSA Key */


int main() {
    RsaKey genKey;
    int result;
    RNG rng;
    FILE *fp;
    wc_InitRng(&rng);

    wc_InitRsaKey(&genKey,0);

    wc_MakeRsaKey(&genKey, 2048, 65537, &rng);
    /*  Save off the private key we are going to use  */
    byte keyDer[4096];
    int keysize, keypemsize;
    keysize = wc_RsaKeyToDer(&genKey, keyDer, 4096);

    byte keypem[4096];
    keypemsize = wc_DerToPem(keyDer, keysize, keypem, 4096, PRIVATEKEY_TYPE);

    /*  Save the new private key */
    fp = fopen("TestprivateKey.pem", "w+");
    fwrite(keypem, 1, keypemsize, fp);
    fclose(fp);

    /*  Create a CERT */
    Cert testcert;
    wc_InitCert(&testcert);

    strcpy(testcert.subject.country, "US");
    strcpy(testcert.subject.state, "ZZ");
    strcpy(testcert.subject.locality, "This City");
    strcpy(testcert.subject.org, "Yada");
    strcpy(testcert.subject.unit, "Dev");
    strcpy(testcert.subject.commonName, "www.whatever.com");
    strcpy(testcert.subject.email, "Info@whatever.com");
    byte dercert[4096];
    int certsize, certpemsize;
    /*  Use for SELF SIGNED */
    //certsize = wc_MakeSelfCert(&testcert, dercert, 4096, &genKey, &rng);

    /*  Use to sign it */
    /*  Load the CA cert to use */
    int cacertbufsize;
    unsigned char cacertbuf[4096];
    byte cacertder[4096];
    fp = fopen("sampleCA.pem", "r");
    cacertbufsize = fread(cacertbuf, 1, 4096, fp);
    fclose(fp);
        /*  Need to convert it to DER  */
    cacertbufsize = wc_CertPemToDer(cacertbuf, cacertbufsize, cacertder, 4096, CERT_TYPE);
    result = wc_SetIssuerBuffer(&testcert, cacertder, cacertbufsize);

    /*  Now we can make the certificate */
    certsize = wc_MakeCert(&testcert, dercert, 4096, &genKey, NULL, &rng);

    /*  Now load the CA key  */
    RsaKey cakey;
    int cakeybufsize;
    unsigned char cakeybuf[4096];
    word32 idx = 0;
    fp = fopen("sampleCAkey.pem", "r");
    cakeybufsize = fread(cakeybuf, 1, 4096, fp);
    fclose(fp);
    unsigned char caderkey[4096];
    /*  Need to conver it to DER  */
    wc_InitRsaKey(&cakey, 0);
    cakeybufsize = wc_KeyPemToDer(cakeybuf, cakeybufsize, caderkey, 4096, "ByteMe");
    result = wc_RsaPrivateKeyDecode((const byte *)caderkey, &idx,&cakey, cakeybufsize);

    /*  Now we sign the certificate  */
    byte signedcert[4096];
    certsize = wc_SignCert(testcert.bodySz, testcert.sigType, signedcert, 4096, &cakey, NULL, &rng);

    /* Convert the DER to PEM  */
    byte pemcert[4096];
    certpemsize = wc_DerToPem(dercert, certsize, pemcert, 4096, CERT_TYPE);

    /*  Save the signed signed cert  */
    fp = fopen("TestprivateCert.pem", "w+");
    fwrite(pemcert, 1, certpemsize, fp);
    fclose(fp);
    return 0;
}

Hello,
Not a question... a complaint.

It has always been my conclusion that anyone who uses "Doxygen" is demonstrating how lacks their work effort it... The output from it is virtually useless.  Developers spend more time in headers formatting, commenting, etc...  then just writing good doc.  Because it spits out header comments as it's source.

Bereft of examples, lacking cross references, one has to know exactly what one is looking for in order to find it.  A serious "cart before the horse" situation.

But developers slap some comments in the headers, let it spit out useless HTML, and they think the job is done.
Then it remains untouched, out of date from enhancements, broken information when something is changed... Because it's forgotten.

If a real document was part of the package, then a real task of updating it would exist.
(The only "real" doc I can find on this product is a PDF from version 3)

From here:
https://www.wolfssl.com/doxygen/group__ … eca15af4c5

" Certificate file type found in asn_public.h enum CertType. "

Go ahead... click it.  It takes you here
https://www.wolfssl.com/doxygen/asn__public_8h.html

There isn't any "CertType" defined anywhere on that page.
Try typing CertType into the search box...  Nothing.

Now start aimlessly wandering through it's useless menu system hoping to stumble on what you are looking for.

Don't think this is just the first incident where I can't find something, and now left wandering aimlessly.  Nor the second time.  Nor the tenth time...  It gets old really fast.

Broken documentation.  Created by an inferior system.

Hello,
I am trying to find doc on wolfSSL_CTX_load_verify_buffer_ex(...).

It doesn't exists ANYWHERE.  I've spend 30 minutes digging and searching, there isn't anything.

Every search takes me to stuff about version 4.2....

The prototype has TWO extra arguments compared to wolfSSL_CTX_load_verify_buffer(...)

One would think there should be only one, to handle the three option flags... But there are two.

And nothing is documented to explain anything.  It's all just Doxygen generated stuff, which should be outlawed for it's lack of usefulness.

Hello.

I am trying to get a client connection to an IIS server. It all works fine in Windows, using a typical TCP connection, linked to a WolfSSL library built with the VS solution file as is from release 4.7.0.

It refuses to work in TI RTOS ARM.  I am coding for the am335x, TI Compiler 17.3, SYSBIOS 6.46

I've been dealing with this for a week, and not getting anywhere.  I've even had to step down into the WolfSSL code trying to debug it.

After MANY REPEATED rebuilds and attempts, I have narrowed it down to enabling:

#define WOLFSSL_SHA384
#define WOLFSSL_SHA512

Simply put:  with those defined, it CRASHES in ecc.c, line 2374 in the function

err = mp_invmod_mont_ct(z, modulus, t1, mp); 

I have not dug any deeper than that into the WOLFSSL code.

Alternately, if I do NOT define those directives, it simply returns from the call to

 result = SSL_connect(m_ssl);

with a code -308  (socket in error condition) which is the result of the server disconnecting on the first Client Hello message.

I keep dragging settings from the Windows build to the TI ARM build to see when it will start working.  All it does is crash with those settings defined.

I've tried to read the doc in order to figure out what #defines need to be defined, with no avail.  There is nothing that tells me "You must enable X if you enable "Y" or it'll crash hard.

The current setting I have defined in "user_settings.h" are:

#define OPENSSL_EXTRA        /*   */

//  From the "settings.h"
    #define FP_MAX_BITS 8192        /*  Increase for 4096 bit key */
    #define USE_CERT_BUFFERS_2048
    #define HAVE_ECC
    #define HAVE_ALPN
    #define USE_WOLF_STRTOK /* use with HAVE_ALPN */
    #define HAVE_TLS_EXTENSIONS
    #define HAVE_AESGCM

//  New settings, trying to get client to connect
#define    WOLFSSL_AES_256
//#define WOLFSSL_SHA384
//#define WOLFSSL_SHA512

#define NO_PSK
#define HAVE_AESGCM
#define ECC_USER_CURVES
#define ECC_SHAMIR
#define WOLFSSL_RIPEMD
#define HAVE_EXTENDED_MASTER

This is the crash from the ARM.  The DFSR shows an access issue, and the DFAR shows address 0

[CortxA8]  0x805dd620  R8  = 0x805d6458
R1 = 0x00000000  R9  = 0x805d6614
R2 = 0x805d661e  R10 = 0x00000e3a
R3 = 0x00000000  R11 = 0x00000000
R4 = 0x00000000  R12 = 0x00000000
R5 = 0x00000000  SP(R13) = 0x805b26e0
R6 = 0x00000001  LR(R14) = 0x804bf1ac
R7 = 0x805dd644  PC(R15) = 0x805b26e0
PSR = 0x00000001
DFSR = 0x00000005  IFSR = 0x00000000
DFAR = 0x00000000  IFAR = 0x00000000
ti.sysbios.family.arm.exc.Exception: line 205: E_dataAbort: pc = 0x805b26e0, lr = 0x804bf1ac.
xdc.runtime.Error.raise: terminating execution

Can anyone clue me in to which of these settings are required to make it simply connect to a IIS server?

-Scott

Hey Kaleb, (or anyone else...)

In the TI_RTOS world, using CCS,  I am trying to load an X509 cert just to examine it.  Logically the functions are:

wolfSSL_X509_load_certificate_buffer()
wolfSSL_X509_get_subject_name()
wolfSSL_X509_NAME_get_entry()

etc...
Except these were unresolved at the linker stage.

So the next logical step was to see what needs to be defined:

#if defined(OPENSSL_EXTRA_X509_SMALL) || defined(KEEP_PEER_CERT) || \
    defined(SESSION_CERTS)

wolfSSL_X509_get_subject_name(  X509)

Okay, so I need OPENSSL_EXTRA_X509_SMALL

But

#if defined(OPENSSL_EXTRA) || defined(WOLFSSL_WPAS_SMALL) || \
    defined(KEEP_PEER_CERT) || defined(SESSION_CERTS)

WOLFSSL_X509* wolfSSL_X509_load_certificate_buffer(...)

This needs OPENSSL_EXTRA

So that looks weird...  You define OPENSSL_EXTRA_X509_SMALL to get the subject name from an X509...  But you can't load an X509 unless you define OPENSSL_EXTRA ??

But that's not what is broken...

In Wolf/src/ssl.c : Line 310087  (in version 4-7) 

/* These constant values are protocol values made by egd */
#if defined(USE_WOLFSSL_IO) && !defined(USE_WINDOWS_API)
    #define WOLFSSL_EGD_NBLOCK 0x01
    #include <sys/un.h>
#endif

Well, TI/CCS has never heard of the header file "un.h".  It's not included in any of the NDK 2-25 or 3-61.  Nor is it in any of the TI compilers, or the GNU compilers they package with CCS.

What am I supposed to do?  I can't comment it out, as there are several functions that use the sockaddr_un structure which is unheard of.  I imagine (but haven't tried) if I try to take that header from from a unix/linux environment, there will be additional conflict and missing declarations.

So as it stands now, the X509 functions can't be used in TI-RTOS because the library wants to include support for Unix local interprocess functions (which are not used in TI_RTOS)

Any suggestions?

Hello,
I have built the WolfSSL as a standalone static library inside CCS, using the TI compiler.

Now I have a bunch of problems trying to do this in CCS with the GNU compiler.

I have a couple of questions regarding what I discovered at the end of this post.

In my opinion, CCS is a trainwreck, and TI is usually of little help.
A lot of this is coming from the *.S files in folder WolfSSL-4-5\Wolf\wolfcrypt\src\port   (root folder is my naming)

And it's because a couple of source files (like "armv8-curve25519.s")  have #includes in it, where most others don't

I compile armv8-curve25519.c  and get 1000's of errors. I can't even see the original command line, since it scrolls off the output so fast...

1.  It shouldn't compile anything because #ifdef WOLFSSL_ARMASM is NOT defined anywhere I can find.  But CCS has a nasty habit of dragging in stuff I don't want, hiding the way things are defined, etc...  So I had to try it another way.

Since the editor highlight is not showing me if #defines are actually defined, I did the following to one of the source files:

#ifdef WOLFSSL_ARMASM
#error  THIS IS ENABLED

This compiled...  But

#error  THIS IS ENABLED
#ifdef WOLFSSL_ARMASM

Gave me the expected error.

So I can tell that WOLFSSL_ARMASM is NOT defined which helps give me a clue for more digging...

2. Next I discover that CCS has decided that it wants to compile the ASSEMBLER FILE armv8-curve25519.S even when I tell it not to. 
I right click on the *.c file, select 'build selected file', but it still compiles the *.S file.
I right click on the *.S file and EXCLUDE IT, but CCS still compiles the *.S file for the *.c file.

(did I say trainweck? I am being polite)

Anyway the *.S file has at the top:

#ifdef HAVE_CONFIG_H
    #include <config.h>
#endif /* HAVE_CONFIG_H */
#include <wolfssl/wolfcrypt/settings.h>

/* Generated using (from wolfssl):
 *   cd ../scripts
 *   ruby ./sha2/sha512.rb arm64 ../wolfssl/wolfcrypt/src/port/arm/armv8-sha512-asm.S
 */
#ifdef WOLFSSL_ARMASM

And the "wolfssl/wolfcrypt/settings.h" file then drags in

#include <ti/sysbios/hal/Seconds.h>

Which then opens the floodgates for XDC and SYSBIOS header files.

The result is that it's reading all the XDC and SYSBIOS code and trying to compile it like assembler.

My solution to work around this is the move the #ifdef to the top...

#ifdef WOLFSSL_ARMASM
#ifdef HAVE_CONFIG_H
    #include <config.h>
#endif /* HAVE_CONFIG_H */
#include <wolfssl/wolfcrypt/settings.h>

Is this a viable workaround?  I don't know why this hasn't been discovered earlier, when someone wants to compile the assembler file.

I see a problem here in that I can never get those assembler files to compile as they have those #includes which breaks the build.

And the assembler files appear to be identical to the code in the C files.  So they appear to be redundant.  It that correct?

Are those ciphers in that folder supported in another way?  Or do I have to enable one of those files (*.c or *.S) to get those ciphers built and included?

Thanks in advance for any advice.