ASN1_STRING type is now opaque

[Blog on OpenSSL Library]

Previous posts about the upcoming OpenSSL 4.0 release:

1. [removing ENGINE code](https://openssl-library.org/post/2025-12-18-remove-engines)
2. [removing deprecated functions for creating or modifying custom METHODS](https://openssl-library.org/post/2026-02-03-remove-methods)
3. [no longer registering a function via atexit function](https://openssl-library.org/post/2026-03-10-remove-atexit)
4. [adding ECH support](https://openssl-library.org/post/2026-03-11-ech)
5. [removing SSLv3 and SSLv2 Client Hello](https://openssl-library.org/post/2026-04-07-ssl3)

## Summary

The ASN1_STRING structure can [no longer be accessed
directly](https://docs.openssl.org/4.0/man7/ossl-guide-migration/#the-
asn1_string-type-is-now-opaque). Instead, accessor functions must be used.

While these accessor functions have been available since OpenSSL 1.0.1, this
change is being made now to enable future work improving X509 memory
efficiency. Requiring accessor functions will allow ASN1 strings to be stored
as pointers to data in read only memory instead of making duplicate copies.



URL: https://openssl-library.org/post/2026-04-13-asn1_string/

[Sands, Daniel N.]

How will EMBED work with this? I can no longer add an ASN1_STRING structure to my temp-to-send data structure since the contents are unknown to the compiler now. Is there a pseudo-native type that can be used in its place, similar to INT32 and INT64 for integers?

>
> The ASN1_STRING structure can [no longer be accessed

> directly](https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> ocs.openssl.org%2F4.0%2Fman7%2Fossl-guide-migration%2F%23the-
> &data=05%7C02%7Cdnsands%40sandia.gov%7Cd1c64df0760e47e2274e08de99
> c13d49%7C7ccb5a20a303498cb0c129007381b574%7C1%7C0%7C63911725240
> 0348398%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%7C&sdata=BnnWtQOjyDFAzL9YmI03Hhs7E5QhOzgr0g1JJmbzuD4%3D&rese
> rved=0