Here`s the second part in a four part series giving a more detailed report of some of the new features present in the recent wolfSSL release.
• UID parsing for x509. Certificates that contain UIDs now have the UID saved for retrieval by wolfSSL. No additional function calls are needed as the UID is contained in the subject or issuer name line and processed like email as part of the Common Name (CN). The UID is prefixed with /UID as the identifier.
• SHA-256 Certificate Signatures. Some certificates are showing up in the wild with SHA-256 certificates though it`s still very unusual. To stay ahead of the curve, wolfSSL now supports certificate and signature verification with SHA-256. No action is needed by the user as this is all done internally.
• Client and server can send certificate chains. Previously, wolfSSL would only send the actual or “bottom” certificate of a chain and rely on the other side to have the rest of the chain available for processing. Now, the user can load all or part of a certificate chain using the function call:
int SSL_CTX_use_certificate_chain_file(SSL_CTX *ctx, const char *file);
file must be in PEM format and must be sorted starting with the subject`s certificate (the actual client or server cert), followed by any intermediate certificates and ending (optionally) at the root “top” CA. The example server now uses this functionality.
• CA loading can now parse multiple certificates per file. wolfSSL is able to load several CAs for verification purposes from one file using the function call:
int SSL_CTX_load_verify_locations(SSL_CTX *ctx, const char *CAfile, const char *CApath);
by passing in a CAfile in PEM format with as many certs as possible. This is useful when a client needs to load several root CAs at startup and makes initialization easier. It also makes it easier to port into tools that expect to be able to use a single file for CAs.
• Dynamic memory runtime hooks. wolfSSL has had a memory abstraction layer for quite some time, allowing the user to take control of dynamic memory handling. This new feature allows the ability to register the memory override functions at runtime instead of compile time. cyassl_memory.h is the header for this functionality and the user can call:
int wolfSSL_SetAllocators(wolfSSL_Malloc_cb malloc_function,
wolfSSL_Free_cb free_function,
wolfSSL_Realloc_cb realloc_function);
to setup the memory functions. Please see the header for the callback prototypes and cyassl_memory.c for the implementation.
Please email us at info@yassl.com or support@yassl.com with any questions regarding the above feature additions, or wolfSSL in general.