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

[Tomas Mraz]

Do you send arbitrary ASN1_STRINGs or some particular subtype? You
could use i2d/d2i to encode and decode concrete ASN1_STRING subtypes.

Tomas Mraz

On Tue, 2026-04-14 at 19:41 +0000, 'Sands, Daniel N.' via openssl-users
wrote:

--
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
We need your support! Help us protect digital privacy… everywhere.
https://openssl.foundation/donate/ways-to-give

[Sands, Daniel N.]

It's typically UTF8 strings. Occasionally it's OCTET strings.

If there were a pseudo-native type of char* for UTF8 and maybe a struct of uint8* and length for OCTET, that would work well for me.

> -----Original Message-----
> From: Tomas Mraz <to...@openssl.foundation>
> Sent: Thursday, April 16, 2026 2:36 AM
> To: Sands, Daniel N. <dns...@sandia.gov>; Blog on OpenSSL Library
> <nor...@openssl.org>; openss...@openssl.org
> Subject: Re: [EXTERNAL] ASN1_STRING type is now opaque
>
> [You don't often get email from to...@openssl.foundation. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]

>
> Do you send arbitrary ASN1_STRINGs or some particular subtype? You could
> use i2d/d2i to encode and decode concrete ASN1_STRING subtypes.
>
> Tomas Mraz
>
> On Tue, 2026-04-14 at 19:41 +0000, 'Sands, Daniel N.' via openssl-users
> wrote:
> > 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%
> > >
> 2F&data=05%7C02%7Cdnsands%40sandia.gov%7C9ecc78d4576448376e20
> 08de9b9
> > >
> 33b68%7C7ccb5a20a303498cb0c129007381b574%7C1%7C0%7C6391192
> 5382248458
> > >
> 6%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA
> uMDAwMC
> > >
> IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&
> sdat
> > >
> a=1eN8QA2iaWNt40GH1CYcMGPOuel%2B4fqCvaenFy3ZXF4%3D&reserved=
> 0
> > > ocs.openssl.org%2F4.0%2Fman7%2Fossl-guide-migration%2F%23the-
> > >
> &data=05%7C02%7Cdnsands%40sandia.gov%7Cd1c64df0760e47e2274e08
> de99
> > >
> c13d49%7C7ccb5a20a303498cb0c129007381b574%7C1%7C0%7C639117
> 25240
> > >
> 0348398%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> OiIw
> > >
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> %7C
> > >
> %7C%7C&sdata=BnnWtQOjyDFAzL9YmI03Hhs7E5QhOzgr0g1JJmbzuD4%3D

> &rese
> > > rved=0
> > > asn1_string-type-is-now-opaque). Instead, accessor functions must be
> > > used.
> > >
>
> --
> Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation We need your

> support! Help us protect digital privacy. everywhere.
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopen
> ssl.foundation%2Fdonate%2Fways-to-
> give&data=05%7C02%7Cdnsands%40sandia.gov%7C9ecc78d4576448376e2
> 008de9b933b68%7C7ccb5a20a303498cb0c129007381b574%7C1%7C0%7
> C639119253822515442%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=6x4jFraPgSL3zu6xULbXmyRXkT6w
> %2F2AWeXqoFpCzzgc%3D&reserved=0