{ "mode": "man", "parameter": "migration_guide", "section": "7ssl", "url": "https://www.chedong.com/phpMan.php/man/migration_guide/7ssl/json", "generated": "2026-10-04T12:32:30Z", "synopsis": "See the individual manual pages for details.", "sections": { "NAME": { "content": "migrationguide - OpenSSL migration guide\n", "subsections": [] }, "SYNOPSIS": { "content": "See the individual manual pages for details.\n", "subsections": [] }, "DESCRIPTION": { "content": "This guide details the changes required to migrate to new versions of OpenSSL. Currently\nthis covers OpenSSL 3.0. For earlier versions refer to\n. For an overview of some of the\nkey concepts introduced in OpenSSL 3.0 see crypto(7).\n\nOPENSSL 3.0", "subsections": [ { "name": "Main Changes from OpenSSL 1.1.1", "content": "Major Release\n\nOpenSSL 3.0 is a major release and consequently any application that currently uses an older\nversion of OpenSSL will at the very least need to be recompiled in order to work with the new\nversion. It is the intention that the large majority of applications will work unchanged with\nOpenSSL 3.0 if those applications previously worked with OpenSSL 1.1.1. However this is not\nguaranteed and some changes may be required in some cases. Changes may also be required if\napplications need to take advantage of some of the new features available in OpenSSL 3.0 such\nas the availability of the FIPS module.\n\nLicense Change\n\nIn previous versions, OpenSSL was licensed under the dual OpenSSL and SSLeay licenses\n (both licenses apply). From\nOpenSSL 3.0 this is replaced by the Apache License v2 .\n\nProviders and FIPS support\n\nOne of the key changes from OpenSSL 1.1.1 is the introduction of the Provider concept.\nProviders collect together and make available algorithm implementations. With OpenSSL 3.0 it\nis possible to specify, either programmatically or via a config file, which providers you\nwant to use for any given application. OpenSSL 3.0 comes with 5 different providers as\nstandard. Over time third parties may distribute additional providers that can be plugged\ninto OpenSSL. All algorithm implementations available via providers are accessed through the\n\"high level\" APIs (for example those functions prefixed with \"EVP\"). They cannot be accessed\nusing the \"Low Level APIs\".\n\nOne of the standard providers available is the FIPS provider. This makes available FIPS\nvalidated cryptographic algorithms. The FIPS provider is disabled by default and needs to be\nenabled explicitly at configuration time using the \"enable-fips\" option. If it is enabled,\nthe FIPS provider gets built and installed in addition to the other standard providers. No\nseparate installation procedure is necessary. There is however a dedicated \"installfips\"\nmake target, which serves the special purpose of installing only the FIPS provider into an\nexisting OpenSSL installation.\n\nNot all algorithms may be available for the application at a particular moment. If the\napplication code uses any digest or cipher algorithm via the EVP interface, the application\nshould verify the result of the EVPEncryptInit(3), EVPEncryptInitex(3), and\nEVPDigestInit(3) functions. In case when the requested algorithm is not available, these\nfunctions will fail.\n\nSee also \"Legacy Algorithms\" for information on the legacy provider.\n\nSee also \"Completing the installation of the FIPS Module\" and \"Using the FIPS Module in\napplications\".\n\nLow Level APIs\n\nOpenSSL has historically provided two sets of APIs for invoking cryptographic algorithms: the\n\"high level\" APIs (such as the \"EVP\" APIs) and the \"low level\" APIs. The high level APIs are\ntypically designed to work across all algorithm types. The \"low level\" APIs are targeted at a\nspecific algorithm implementation. For example, the EVP APIs provide the functions\nEVPEncryptInitex(3), EVPEncryptUpdate(3) and EVPEncryptFinal(3) to perform symmetric\nencryption. Those functions can be used with the algorithms AES, CHACHA, 3DES etc. On the\nother hand, to do AES encryption using the low level APIs you would have to call AES specific\nfunctions such as AESsetencryptkey(3), AESencrypt(3), and so on. The functions for 3DES\nare different. Use of the low level APIs has been informally discouraged by the OpenSSL\ndevelopment team for a long time. However in OpenSSL 3.0 this is made more formal. All such\nlow level APIs have been deprecated. You may still use them in your applications, but you may\nstart to see deprecation warnings during compilation (dependent on compiler support for\nthis). Deprecated APIs may be removed from future versions of OpenSSL so you are strongly\nencouraged to update your code to use the high level APIs instead.\n\nThis is described in more detail in \"Deprecation of Low Level Functions\"\n\nLegacy Algorithms\n\nSome cryptographic algorithms such as MD2 and DES that were available via the EVP APIs are\nnow considered legacy and their use is strongly discouraged. These legacy EVP algorithms are\nstill available in OpenSSL 3.0 but not by default. If you want to use them then you must load\nthe legacy provider. This can be as simple as a config file change, or can be done\nprogrammatically. See OSSLPROVIDER-legacy(7) for a complete list of algorithms.\nApplications using the EVP APIs to access these algorithms should instead use more modern\nalgorithms. If that is not possible then these applications should ensure that the legacy\nprovider has been loaded. This can be achieved either programmatically or via configuration.\nSee crypto(7) man page for more information about providers.\n\nEngines and \"METHOD\" APIs\n\nThe refactoring to support Providers conflicts internally with the APIs used to support\nengines, including the ENGINE API and any function that creates or modifies custom \"METHODS\"\n(for example EVPMDmethnew(3), EVPCIPHERmethnew(3), EVPPKEYmethnew(3),\nRSAmethnew(3), ECKEYMETHODnew(3), etc.). These functions are being deprecated in OpenSSL\n3.0, and users of these APIs should know that their use can likely bypass provider selection\nand configuration, with unintended consequences. This is particularly relevant for\napplications written to use the OpenSSL 3.0 FIPS module, as detailed below. Authors and\nmaintainers of external engines are strongly encouraged to refactor their code transforming\nengines into providers using the new Provider API and avoiding deprecated methods.\n\nSupport of legacy engines\n\nIf openssl is not built without engine support or deprecated API support, engines will still\nwork. However, their applicability will be limited.\n\nNew algorithms provided via engines will still work.\n\nEngine-backed keys can be loaded via custom OSSLSTORE implementation. In this case the\nEVPPKEY objects created via ENGINEloadprivatekey(3) will be considered legacy and will\ncontinue to work.\n\nTo ensure the future compatibility, the engines should be turned to providers. To prefer the\nprovider-based hardware offload, you can specify the default properties to prefer your\nprovider.\n\nVersioning Scheme\n\nThe OpenSSL versioning scheme has changed with the OpenSSL 3.0 release. The new versioning\nscheme has this format:\n\nMAJOR.MINOR.PATCH\n\nFor OpenSSL 1.1.1 and below, different patch levels were indicated by a letter at the end of\nthe release version number. This will no longer be used and instead the patch level is\nindicated by the final number in the version. A change in the second (MINOR) number indicates\nthat new features may have been added. OpenSSL versions with the same major number are API\nand ABI compatible. If the major number changes then API and ABI compatibility is not\nguaranteed.\n\nFor more information, see OpenSSLversion(3).\n\nOther major new features\n\nCertificate Management Protocol (CMP, RFC 4210)\n\nThis also covers CRMF (RFC 4211) and HTTP transfer (RFC 6712) See openssl-cmp(1) and\nOSSLCMPexeccertreq(3) as starting points.\n\nHTTP(S) client\n\nA proper HTTP(S) client that supports GET and POST, redirection, plain and ASN.1-encoded\ncontents, proxies, and timeouts.\n\nKey Derivation Function API (EVPKDF)\n\nThis simplifies the process of adding new KDF and PRF implementations.\n\nPreviously KDF algorithms had been shoe-horned into using the EVPPKEY object which was not a\nlogical mapping. Existing applications that use KDF algorithms using EVPPKEY (scrypt, TLS1\nPRF and HKDF) may be slower as they use an EVPKDF bridge internally. All new applications\nshould use the new EVPKDF(3) interface. See also \"Key Derivation Function (KDF)\" in\nOSSLPROVIDER-default(7) and \"Key Derivation Function (KDF)\" in OSSLPROVIDER-FIPS(7).\n\nMessage Authentication Code API (EVPMAC)\n\nThis simplifies the process of adding MAC implementations.\n\nThis includes a generic EVPPKEY to EVPMAC bridge, to facilitate the continued use of MACs\nthrough raw private keys in functionality such as EVPDigestSign(3) and EVPDigestVerify(3).\n\nAll new applications should use the new EVPMAC(3) interface. See also \"Message\nAuthentication Code (MAC)\" in OSSLPROVIDER-default(7) and \"Message Authentication Code\n(MAC)\" in OSSLPROVIDER-FIPS(7).\n\nAlgorithm Fetching\n\nUsing calls to convenience functions such as EVPsha256() and EVPaes256gcm() may incur a\nperformance penalty when using providers. Retrieving algorithms from providers involves\nsearching for an algorithm by name. This is much slower than directly accessing a method\ntable. It is recommended to prefetch algorithms if an algorithm is used many times. See\n\"Performance\" in crypto(7), \"Explicit fetching\" in crypto(7) and \"Implicit fetching\" in\ncrypto(7).\n\nSupport for Linux Kernel TLS\n\nIn order to use KTLS, support for it must be compiled in using the \"enable-ktls\"\nconfiguration option. It must also be enabled at run time using the SSLOPENABLEKTLS\noption.\n\nNew Algorithms\n\n• KDF algorithms \"SINGLE STEP\" and \"SSH\"\n\nSee EVPKDF-SS(7) and EVPKDF-SSHKDF(7)\n\n• MAC Algorithms \"GMAC\" and \"KMAC\"\n\nSee EVPMAC-GMAC(7) and EVPMAC-KMAC(7).\n\n• KEM Algorithm \"RSASVE\"\n\nSee EVPKEM-RSA(7).\n\n• Cipher Algorithm \"AES-SIV\"\n\nSee \"SIV Mode\" in EVPEncryptInit(3).\n\n• AES Key Wrap inverse ciphers supported by EVP layer.\n\nThe inverse ciphers use AES decryption for wrapping, and AES encryption for unwrapping.\nThe algorithms are: \"AES-128-WRAP-INV\", \"AES-192-WRAP-INV\", \"AES-256-WRAP-INV\",\n\"AES-128-WRAP-PAD-INV\", \"AES-192-WRAP-PAD-INV\" and \"AES-256-WRAP-PAD-INV\".\n\n• CTS ciphers added to EVP layer.\n\nThe algorithms are \"AES-128-CBC-CTS\", \"AES-192-CBC-CTS\", \"AES-256-CBC-CTS\",\n\"CAMELLIA-128-CBC-CTS\", \"CAMELLIA-192-CBC-CTS\" and \"CAMELLIA-256-CBC-CTS\". CS1, CS2 and\nCS3 variants are supported.\n\nCMS and PKCS#7 updates\n\n• Added CAdES-BES signature verification support.\n\n• Added CAdES-BES signature scheme and attributes support (RFC 5126) to CMS API.\n\n• Added AuthEnvelopedData content type structure (RFC 5083) using AESGCM\n\nThis uses the AES-GCM parameter (RFC 5084) for the Cryptographic Message Syntax. Its\npurpose is to support encryption and decryption of a digital envelope that is both\nauthenticated and encrypted using AES GCM mode.\n\n• PKCS7getoctetstring(3) and PKCS7typeisother(3) were made public.\n\nPKCS#12 API updates\n\nThe default algorithms for pkcs12 creation with the PKCS12create() function were changed to\nmore modern PBKDF2 and AES based algorithms. The default MAC iteration count was changed to\nPKCS12DEFAULTITER to make it equal with the password-based encryption iteration count. The\ndefault digest algorithm for the MAC computation was changed to SHA-256. The pkcs12\napplication now supports -legacy option that restores the previous default algorithms to\nsupport interoperability with legacy systems.\n\nAdded enhanced PKCS#12 APIs which accept a library context OSSLLIBCTX and (where relevant)\na property query. Other APIs which handle PKCS#7 and PKCS#8 objects have also been enhanced\nwhere required. This includes:\n\nPKCS12addkeyex(3), PKCS12addsafeex(3), PKCS12addsafesex(3), PKCS12createex(3),\nPKCS12decryptskeyex(3), PKCS12initex(3), PKCS12itemdecryptd2iex(3),\nPKCS12itemi2dencryptex(3), PKCS12keygenascex(3), PKCS12keygenuniex(3),\nPKCS12keygenutf8ex(3), PKCS12packp7encdataex(3), PKCS12pbecryptex(3),\nPKCS12PBEkeyivgenex(3), PKCS12SAFEBAGcreatepkcs8encryptex(3),\nPKCS5pbe2setivex(3), PKCS5pbeset0algorex(3), PKCS5pbesetex(3),\nPKCS5pbkdf2setex(3), PKCS5v2PBEkeyivgenex(3), PKCS5v2scryptkeyivgenex(3),\nPKCS8decryptex(3), PKCS8encryptex(3), PKCS8set0pbeex(3).\n\nAs part of this change the EVPPBExxx APIs can also accept a library context and property\nquery and will call an extended version of the key/IV derivation function which supports\nthese parameters. This includes EVPPBECipherInitex(3), EVPPBEfindex(3) and\nEVPPBEscryptex(3).\n\nPKCS#12 KDF versus FIPS\n\nUnlike in 1.x.y, the PKCS12KDF algorithm used when a PKCS#12 structure is created with a MAC\nthat does not work with the FIPS provider as the PKCS12KDF is not a FIPS approvable\nmechanism.\n\nSee EVPKDF-PKCS12KDF(7), PKCS12create(3), openssl-pkcs12(1), OSSLPROVIDER-FIPS(7).\n\nWindows thread synchronization changes\n\nWindows thread synchronization uses read/write primitives (SRWLock) when supported by the OS,\notherwise CriticalSection continues to be used.\n\nTrace API\n\nA new generic trace API has been added which provides support for enabling instrumentation\nthrough trace output. This feature is mainly intended as an aid for developers and is\ndisabled by default. To utilize it, OpenSSL needs to be configured with the \"enable-trace\"\noption.\n\nIf the tracing API is enabled, the application can activate trace output by registering BIOs\nas trace channels for a number of tracing and debugging categories. See\nOSSLtraceenabled(3).\n\nKey validation updates\n\nEVPPKEYpubliccheck(3) and EVPPKEYparamcheck(3) now work for more key types. This\nincludes RSA, DSA, ED25519, X25519, ED448 and X448. Previously (in 1.1.1) they would return\n-2. For key types that do not have parameters then EVPPKEYparamcheck(3) will always return\n1.\n\nOther notable deprecations and changes\n\nThe function code part of an OpenSSL error code is no longer relevant\n\nThis code is now always set to zero. Related functions are deprecated.\n\nSTACK and HASH macros have been cleaned up\n\nThe type-safe wrappers are declared everywhere and implemented once. See DEFINESTACKOF(3)\nand DECLARELHASHOF(3).\n\nThe RANDDRBG subsystem has been removed\n\nThe new EVPRAND(3) is a partial replacement: the DRBG callback framework is absent. The\nRANDDRBG API did not fit well into the new provider concept as implemented by EVPRAND and\nEVPRANDCTX.\n\nRemoved FIPSmode() and FIPSmodeset()\n\nThese functions are legacy APIs that are not applicable to the new provider model.\nApplications should instead use EVPdefaultpropertiesisfipsenabled(3) and\nEVPdefaultpropertiesenablefips(3).\n\nKey generation is slower\n\nThe Miller-Rabin test now uses 64 rounds, which is used for all prime generation, including\nRSA key generation. This affects the time for larger keys sizes.\n\nThe default key generation method for the regular 2-prime RSA keys was changed to the\nFIPS186-4 B.3.6 method (Generation of Probable Primes with Conditions Based on Auxiliary\nProbable Primes). This method is slower than the original method.\n\nChange PBKDF2 to conform to SP800-132 instead of the older PKCS5 RFC2898\n\nThis checks that the salt length is at least 128 bits, the derived key length is at least 112\nbits, and that the iteration count is at least 1000. For backwards compatibility these\nchecks are disabled by default in the default provider, but are enabled by default in the\nFIPS provider.\n\nTo enable or disable the checks see OSSLKDFPARAMPKCS5 in EVPKDF-PBKDF2(7). The parameter\ncan be set using EVPKDFderive(3).\n\nEnforce a minimum DH modulus size of 512 bits\n\nSmaller sizes now result in an error.\n\nSM2 key changes\n\nEC EVPPKEYs with the SM2 curve have been reworked to automatically become EVPPKEYSM2\nrather than EVPPKEYEC.\n\nUnlike in previous OpenSSL versions, this means that applications cannot call\n\"EVPPKEYsetaliastype(pkey, EVPPKEYSM2)\" to get SM2 computations.\n\nParameter and key generation is also reworked to make it possible to generate EVPPKEYSM2\nparameters and keys. Applications must now generate SM2 keys directly and must not create an\nEVPPKEYEC key first. It is no longer possible to import an SM2 key with domain parameters\nother than the SM2 elliptic curve ones.\n\nValidation of SM2 keys has been separated from the validation of regular EC keys, allowing to\nimprove the SM2 validation process to reject loaded private keys that are not conforming to\nthe SM2 ISO standard. In particular, a private scalar k outside the range 1 <= k < n-1 is\nnow correctly rejected.\n\nEVPPKEYsetaliastype() method has been removed\n\nThis function made a EVPPKEY object mutable after it had been set up. In OpenSSL 3.0 it was\ndecided that a provided key should not be able to change its type, so this function has been\nremoved.\n\nFunctions that return an internal key should be treated as read only\n\nFunctions such as EVPPKEYget0RSA(3) behave slightly differently in OpenSSL 3.0. Previously\nthey returned a pointer to the low-level key used internally by libcrypto. From OpenSSL 3.0\nthis key may now be held in a provider. Calling these functions will only return a handle on\nthe internal key where the EVPPKEY was constructed using this key in the first place, for\nexample using a function or macro such as EVPPKEYassignRSA(3), EVPPKEYset1RSA(3), etc.\nWhere the EVPPKEY holds a provider managed key, then these functions now return a cached\ncopy of the key. Changes to the internal provider key that take place after the first time\nthe cached key is accessed will not be reflected back in the cached copy. Similarly any\nchanges made to the cached copy by application code will not be reflected back in the\ninternal provider key.\n\nFor the above reasons the keys returned from these functions should typically be treated as\nread-only. To emphasise this the value returned from EVPPKEYget0RSA(3),\nEVPPKEYget0DSA(3), EVPPKEYget0ECKEY(3) and EVPPKEYget0DH(3) have been made const.\nThis may break some existing code. Applications broken by this change should be modified.\nThe preferred solution is to refactor the code to avoid the use of these deprecated\nfunctions. Failing this the code should be modified to use a const pointer instead. The\nEVPPKEYget1RSA(3), EVPPKEYget1DSA(3), EVPPKEYget1ECKEY(3) and EVPPKEYget1DH(3)\nfunctions continue to return a non-const pointer to enable them to be \"freed\". However they\nshould also be treated as read-only.\n\nThe public key check has moved from EVPPKEYderive() to EVPPKEYderivesetpeer()\n\nThis may mean result in an error in EVPPKEYderivesetpeer(3) rather than during\nEVPPKEYderive(3). To disable this check use EVPPKEYderivesetpeerex(dh, peer, 0).\n\nThe print format has cosmetic changes for some functions\n\nThe output from numerous \"printing\" functions such as X509signatureprint(3),\nX509printex(3), X509CRLprintex(3), and other similar functions has been amended such\nthat there may be cosmetic differences between the output observed in 1.1.1 and 3.0. This\nalso applies to the -text output from the openssl x509 and openssl crl applications.\n\nInteractive mode from the openssl program has been removed\n\nFrom now on, running it without arguments is equivalent to openssl help.\n\nThe error return values from some control calls (ctrl) have changed\n\nOne significant change is that controls which used to return -2 for invalid inputs, now\nreturn -1 indicating a generic error condition instead.\n\nDH and DHX key types have different settable parameters\n\nPreviously (in 1.1.1) these conflicting parameters were allowed, but will now result in\nerrors. See EVPPKEY-DH(7) for further details. This affects the behaviour of\nopenssl-genpkey(1) for DH parameter generation.\n\nEVPCIPHERCTXsetflags() ordering change\n\nIf using a cipher from a provider the EVPCIPHFLAGLENGTHBITS flag can only be set after\nthe cipher has been assigned to the cipher context. See \"FLAGS\" in EVPEncryptInit(3) for\nmore information.\n\nValidation of operation context parameters\n\nDue to move of the implementation of cryptographic operations to the providers, validation of\nvarious operation parameters can be postponed until the actual operation is executed where\npreviously it happened immediately when an operation parameter was set.\n\nFor example when setting an unsupported curve with EVPPKEYCTXsetecparamgencurvenid()\nthis function call will not fail but later keygen operations with the EVPPKEYCTX will fail.\n\nRemoval of function code from the error codes\n\nThe function code part of the error code is now always set to 0. For that reason the\nERRGETFUNC() macro was removed. Applications must resolve the error codes only using the\nlibrary number and the reason code.\n\nChaCha20-Poly1305 cipher does not allow a truncated IV length to be used\n\nIn OpenSSL 3.0 setting the IV length to any value other than 12 will result in an error.\nPrior to OpenSSL 3.0 the ivlen could be smaller that the required 12 byte length, using\nEVPCIPHERCTXctrl(ctx, EVPCRTLAEADSETIVLEN, ivlen, NULL). This resulted in an IV that\nhad leading zero padding.\n" }, { "name": "Installation and Compilation", "content": "Please refer to the INSTALL.md file in the top of the distribution for instructions on how to\nbuild and install OpenSSL 3.0. Please also refer to the various platform specific NOTES files\nfor your specific platform.\n" }, { "name": "Upgrading from OpenSSL 1.1.1", "content": "Upgrading to OpenSSL 3.0 from OpenSSL 1.1.1 should be relatively straight forward in most\ncases. The most likely area where you will encounter problems is if you have used low level\nAPIs in your code (as discussed above). In that case you are likely to start seeing\ndeprecation warnings when compiling your application. If this happens you have 3 options:\n\n1. Ignore the warnings. They are just warnings. The deprecated functions are still present\nand you may still use them. However be aware that they may be removed from a future\nversion of OpenSSL.\n\n2. Suppress the warnings. Refer to your compiler documentation on how to do this.\n\n3. Remove your usage of the low level APIs. In this case you will need to rewrite your code\nto use the high level APIs instead\n\nError code changes\n\nAs OpenSSL 3.0 provides a brand new Encoder/Decoder mechanism for working with widely used\nfile formats, application code that checks for particular error reason codes on key loading\nfailures might need an update.\n\nPassword-protected keys may deserve special attention. If only some errors are treated as an\nindicator that the user should be asked about the password again, it's worth testing these\nscenarios and processing the newly relevant codes.\n\nThere may be more cases to treat specially, depending on the calling application code.\n" }, { "name": "Upgrading from OpenSSL 1.0.2", "content": "Upgrading to OpenSSL 3.0 from OpenSSL 1.0.2 is likely to be significantly more difficult. In\naddition to the issues discussed above in the section about \"Upgrading from OpenSSL 1.1.1\",\nthe main things to be aware of are:\n\n1. The build and installation procedure has changed significantly.\n\nCheck the file INSTALL.md in the top of the installation for instructions on how to build\nand install OpenSSL for your platform. Also read the various NOTES files in the same\ndirectory, as applicable for your platform.\n\n2. Many structures have been made opaque in OpenSSL 3.0.\n\nThe structure definitions have been removed from the public header files and moved to\ninternal header files. In practice this means that you can no longer stack allocate some\nstructures. Instead they must be heap allocated through some function call (typically\nthose function names have a \"new\" suffix to them). Additionally you must use \"setter\"\nor \"getter\" functions to access the fields within those structures.\n\nFor example code that previously looked like this:\n\nEVPMDCTX mdctx;\n\n/* This line will now generate compiler errors */\nEVPMDCTXinit(&mdctx);\n\nThe code needs to be amended to look like this:\n\nEVPMDCTX *mdctx;\n\nmdctx = EVPMDCTXnew();\n...\n...\nEVPMDCTXfree(mdctx);\n\n3. Support for TLSv1.3 has been added.\n\nThis has a number of implications for SSL/TLS applications. See the TLS1.3 page\n for further details.\n\nMore details about the breaking changes between OpenSSL versions 1.0.2 and 1.1.0 can be found\non the OpenSSL 1.1.0 Changes page .\n\nUpgrading from the OpenSSL 2.0 FIPS Object Module\n\nThe OpenSSL 2.0 FIPS Object Module was a separate download that had to be built separately\nand then integrated into your main OpenSSL 1.0.2 build. In OpenSSL 3.0 the FIPS support is\nfully integrated into the mainline version of OpenSSL and is no longer a separate download.\nFor further information see \"Completing the installation of the FIPS Module\".\n\nThe function calls FIPSmode() and FIPSmodeset() have been removed from OpenSSL 3.0. You\nshould rewrite your application to not use them. See fipsmodule(7) and\nOSSLPROVIDER-FIPS(7) for details.\n" }, { "name": "Completing the installation of the FIPS Module", "content": "The FIPS Module will be built and installed automatically if FIPS support has been\nconfigured. The current documentation can be found in the README-FIPS\n file.\n" }, { "name": "Programming", "content": "Applications written to work with OpenSSL 1.1.1 will mostly just work with OpenSSL 3.0.\nHowever changes will be required if you want to take advantage of some of the new features\nthat OpenSSL 3.0 makes available. In order to do that you need to understand some new\nconcepts introduced in OpenSSL 3.0. Read \"Library contexts\" in crypto(7) for further\ninformation.\n\nLibrary Context\n\nA library context allows different components of a complex application to each use a\ndifferent library context and have different providers loaded with different configuration\nsettings. See \"Library contexts\" in crypto(7) for further info.\n\nIf the user creates an OSSLLIBCTX via OSSLLIBCTXnew(3) then many functions may need to\nbe changed to pass additional parameters to handle the library context.\n\nUsing a Library Context - Old functions that should be changed\n\nIf a library context is needed then all EVP* digest functions that return a const EVPMD *\nsuch as EVPsha256() should be replaced with a call to EVPMDfetch(3). See \"ALGORITHM\nFETCHING\" in crypto(7).\n\nIf a library context is needed then all EVP* cipher functions that return a const EVPCIPHER\n* such as EVPaes128cbc() should be replaced vith a call to EVPCIPHERfetch(3). See\n\"ALGORITHM FETCHING\" in crypto(7).\n\nSome functions can be passed an object that has already been set up with a library context\nsuch as d2iX509(3), d2iX509CRL(3), d2iX509REQ(3) and d2iX509PUBKEY(3). If NULL is\npassed instead then the created object will be set up with the default library context. Use\nX509newex(3), X509CRLnewex(3), X509REQnewex(3) and X509PUBKEYnewex(3) if a library\ncontext is required.\n\nAll functions listed below with a NAME have a replacement function NAMEex that takes\nOSSLLIBCTX as an additional argument. Functions that have other mappings are listed along\nwith the respective name.\n\n• ASN1itemnew(3), ASN1itemd2i(3), ASN1itemd2ifp(3), ASN1itemd2ibio(3),\nASN1itemsign(3) and ASN1itemverify(3)\n\n• BIOnew(3)\n\n• b2iRSAPVKbio() and i2bPVKbio()\n\n• BNCTXnew(3) and BNCTXsecurenew(3)\n\n• CMSAuthEnvelopedDatacreate(3), CMSContentInfonew(3), CMSdatacreate(3),\nCMSdigestcreate(3), CMSEncryptedDataencrypt(3), CMSencrypt(3),\nCMSEnvelopedDatacreate(3), CMSReceiptRequestcreate0(3) and CMSsign(3)\n\n• CONFmodulesloadfile(3)\n\n• CTLOGnew(3), CTLOGnewfrombase64(3) and CTLOGSTOREnew(3)\n\n• CTPOLICYEVALCTXnew(3)\n\n• d2iAutoPrivateKey(3), d2iPrivateKey(3) and d2iPUBKEY(3)\n\n• d2iPrivateKeybio(3) and d2iPrivateKeyfp(3)\n\nUse d2iPrivateKeyexbio(3) and d2iPrivateKeyexfp(3)\n\n• ECGROUPnew(3)\n\nUse ECGROUPnewbycurvenameex(3) or ECGROUPnewfromparams(3).\n\n• EVPDigestSignInit(3) and EVPDigestVerifyInit(3)\n\n• EVPPBECipherInit(3), EVPPBEfind(3) and EVPPBEscrypt(3)\n\n• PKCS5PBEkeyivgen(3)\n\n• EVPPKCS82PKEY(3)\n\n• EVPPKEYCTXnewid(3)\n\nUse EVPPKEYCTXnewfromname(3)\n\n• EVPPKEYderivesetpeer(3), EVPPKEYnewrawprivatekey(3) and\nEVPPKEYnewrawpublickey(3)\n\n• EVPSignFinal(3) and EVPVerifyFinal(3)\n\n• NCONFnew(3)\n\n• OCSPRESPIDmatch(3) and OCSPRESPIDsetbykey(3)\n\n• OPENSSLthreadstop(3)\n\n• OSSLSTOREopen(3)\n\n• PEMreadbioParameters(3), PEMreadbioPrivateKey(3), PEMreadbioPUBKEY(3),\nPEMreadPrivateKey(3) and PEMreadPUBKEY(3)\n\n• PEMwritebioPrivateKey(3), PEMwritebioPUBKEY(3), PEMwritePrivateKey(3) and\nPEMwritePUBKEY(3)\n\n• PEMX509INFOreadbio(3) and PEMX509INFOread(3)\n\n• PKCS12addkey(3), PKCS12addsafe(3), PKCS12addsafes(3), PKCS12create(3),\nPKCS12decryptskey(3), PKCS12init(3), PKCS12itemdecryptd2i(3),\nPKCS12itemi2dencrypt(3), PKCS12keygenasc(3), PKCS12keygenuni(3),\nPKCS12keygenutf8(3), PKCS12packp7encdata(3), PKCS12pbecrypt(3),\nPKCS12PBEkeyivgen(3), PKCS12SAFEBAGcreatepkcs8encrypt(3)\n\n• PKCS5pbeset0algor(3), PKCS5pbeset(3), PKCS5pbe2setiv(3), PKCS5pbkdf2set(3) and\nPKCS5v2scryptkeyivgen(3)\n\n• PKCS7encrypt(3), PKCS7new(3) and PKCS7sign(3)\n\n• PKCS8decrypt(3), PKCS8encrypt(3) and PKCS8set0pbe(3)\n\n• RANDbytes(3) and RANDprivbytes(3)\n\n• SMIMEwriteASN1(3)\n\n• SSLloadclientCAfile(3)\n\n• SSLCTXnew(3)\n\n• TSRESPCTXnew(3)\n\n• X509CRLnew(3)\n\n• X509loadcertcrlfile(3) and X509loadcertfile(3)\n\n• X509LOOKUPbysubject(3) and X509LOOKUPctrl(3)\n\n• X509NAMEhash(3)\n\n• X509new(3)\n\n• X509REQnew(3) and X509REQverify(3)\n\n• X509STORECTXnew(3), X509STOREsetdefaultpaths(3), X509STOREloadfile(3),\nX509STOREloadlocations(3) and X509STOREloadstore(3)\n\nNew functions that use a Library context\n\nThe following functions can be passed a library context if required. Passing NULL will use\nthe default library context.\n\n• BIOnewfromcorebio(3)\n\n• EVPASYMCIPHERfetch(3) and EVPASYMCIPHERdoallprovided(3)\n\n• EVPCIPHERfetch(3) and EVPCIPHERdoallprovided(3)\n\n• EVPdefaultpropertiesenablefips(3) and EVPdefaultpropertiesisfipsenabled(3)\n\n• EVPKDFfetch(3) and EVPKDFdoallprovided(3)\n\n• EVPKEMfetch(3) and EVPKEMdoallprovided(3)\n\n• EVPKEYEXCHfetch(3) and EVPKEYEXCHdoallprovided(3)\n\n• EVPKEYMGMTfetch(3) and EVPKEYMGMTdoallprovided(3)\n\n• EVPMACfetch(3) and EVPMACdoallprovided(3)\n\n• EVPMDfetch(3) and EVPMDdoallprovided(3)\n\n• EVPPKEYCTXnewfrompkey(3)\n\n• EVPPKEYQkeygen(3)\n\n• EVPQmac(3) and EVPQdigest(3)\n\n• EVPRAND(3) and EVPRANDdoallprovided(3)\n\n• EVPsetdefaultproperties(3)\n\n• EVPSIGNATUREfetch(3) and EVPSIGNATUREdoallprovided(3)\n\n• OSSLCMPCTXnew(3) and OSSLCMPSRVCTXnew(3)\n\n• OSSLCRMFENCRYPTEDVALUEget1encCert(3)\n\n• OSSLCRMFMSGcreatepopo(3) and OSSLCRMFMSGSverifypopo(3)\n\n• OSSLCRMFpbmnew(3) and OSSLCRMFpbmpnew(3)\n\n• OSSLDECODERCTXaddextra(3) and OSSLDECODERCTXnewforpkey(3)\n\n• OSSLDECODERfetch(3) and OSSLDECODERdoallprovided(3)\n\n• OSSLENCODERCTXaddextra(3)\n\n• OSSLENCODERfetch(3) and OSSLENCODERdoallprovided(3)\n\n• OSSLLIBCTXfree(3), OSSLLIBCTXloadconfig(3) and OSSLLIBCTXset0default(3)\n\n• OSSLPROVIDERaddbuiltin(3), OSSLPROVIDERavailable(3), OSSLPROVIDERdoall(3),\nOSSLPROVIDERload(3), OSSLPROVIDERsetdefaultsearchpath(3) and\nOSSLPROVIDERtryload(3)\n\n• OSSLSELFTESTgetcallback(3) and OSSLSELFTESTsetcallback(3)\n\n• OSSLSTOREattach(3)\n\n• OSSLSTORELOADERfetch(3) and OSSLSTORELOADERdoallprovided(3)\n\n• RANDget0primary(3), RANDget0private(3), RANDget0public(3), RANDsetDRBGtype(3)\nand RANDsetseedsourcetype(3)\n\nProviders\n\nProviders are described in detail here \"Providers\" in crypto(7). See also \"OPENSSL\nPROVIDERS\" in crypto(7).\n\nFetching algorithms and property queries\n\nImplicit and Explicit Fetching is described in detail here \"ALGORITHM FETCHING\" in crypto(7).\n\nMapping EVP controls and flags to provider OSSLPARAM(3) parameters\n\nThe existing functions for controls (such as EVPCIPHERCTXctrl(3)) and manipulating flags\n(such as EVPMDCTXsetflags(3))internally use OSSLPARAMS to pass information to/from\nprovider objects. See OSSLPARAM(3) for additional information related to parameters.\n\nFor ciphers see \"CONTROLS\" in EVPEncryptInit(3), \"FLAGS\" in EVPEncryptInit(3) and\n\"PARAMETERS\" in EVPEncryptInit(3).\n\nFor digests see \"CONTROLS\" in EVPDigestInit(3), \"FLAGS\" in EVPDigestInit(3) and\n\"PARAMETERS\" in EVPDigestInit(3).\n\nDeprecation of Low Level Functions\n\nA significant number of APIs have been deprecated in OpenSSL 3.0. This section describes\nsome common categories of deprecations. See \"Deprecated function mappings\" for the list of\ndeprecated functions that refer to these categories.\n\nProviders are a replacement for engines and low-level method overrides\n\nAny accessor that uses an ENGINE is deprecated (such as EVPPKEYset1engine()).\nApplications using engines should instead use providers.\n\nBefore providers were added algorithms were overridden by changing the methods used by\nalgorithms. All these methods such as RSAnewmethod() and RSAmethnew() are now deprecated\nand can be replaced by using providers instead.\n\nDeprecated i2d and d2i functions for low-level key types\n\nAny i2d and d2i functions such as d2iDHparams() that take a low-level key type have been\ndeprecated. Applications should instead use the OSSLDECODER(3) and OSSLENCODER(3) APIs to\nread and write files. See \"Migration\" in d2iRSAPrivateKey(3) for further details.\n\nDeprecated low-level key object getters and setters\n\nApplications that set or get low-level key objects (such as EVPPKEYset1DH() or\nEVPPKEYget0()) should instead use the OSSLENCODER (See OSSLENCODERtobio(3)) or\nOSSLDECODER (See OSSLDECODERfrombio(3)) APIs, or alternatively use EVPPKEYfromdata(3)\nor EVPPKEYtodata(3).\n\nDeprecated low-level key parameter getters\n\nFunctions that access low-level objects directly such as RSAget0n(3) are now deprecated.\nApplications should use one of EVPPKEYgetbnparam(3), EVPPKEYgetintparam(3),\nl, EVPPKEYgetutf8stringparam(3),\nEVPPKEYgetoctetstringparam(3) or EVPPKEYgetparams(3) to access fields from an\nEVPPKEY. Gettable parameters are listed in \"Common RSA parameters\" in EVPPKEY-RSA(7), \"DH\nparameters\" in EVPPKEY-DH(7), \"DSA parameters\" in EVPPKEY-DSA(7), \"FFC parameters\" in\nEVPPKEY-FFC(7), \"Common EC parameters\" in EVPPKEY-EC(7) and \"Common X25519, X448, ED25519\nand ED448 parameters\" in EVPPKEY-X25519(7). Applications may also use EVPPKEYtodata(3) to\nreturn all fields.\n\nDeprecated low-level key parameter setters\n\nFunctions that access low-level objects directly such as RSAset0crtparams(3) are now\ndeprecated. Applications should use EVPPKEYfromdata(3) to create new keys from user\nprovided key data. Keys should be immutable once they are created, so if required the user\nmay use EVPPKEYtodata(3), OSSLPARAMmerge(3), and EVPPKEYfromdata(3) to create a\nmodified key. See \"Examples\" in EVPPKEY-DH(7) for more information. See \"Deprecated low-\nlevel key generation functions\" for information on generating a key using parameters.\n\nDeprecated low-level object creation\n\nLow-level objects were created using methods such as RSAnew(3), RSAupref(3) and\nRSAfree(3). Applications should instead use the high-level EVPPKEY APIs, e.g.\nEVPPKEYnew(3), EVPPKEYupref(3) and EVPPKEYfree(3). See also\nEVPPKEYCTXnewfromname(3) and EVPPKEYCTXnewfrompkey(3).\n\nEVPPKEYs may be created in a variety of ways: See also \"Deprecated low-level key generation\nfunctions\", \"Deprecated low-level key reading and writing functions\" and \"Deprecated low-\nlevel key parameter setters\".\n\nDeprecated low-level encryption functions\n\nLow-level encryption functions such as AESencrypt(3) and AESdecrypt(3) have been informally\ndiscouraged from use for a long time. Applications should instead use the high level EVP APIs\nEVPEncryptInitex(3), EVPEncryptUpdate(3), and EVPEncryptFinalex(3) or\nEVPDecryptInitex(3), EVPDecryptUpdate(3) and EVPDecryptFinalex(3).\n\nDeprecated low-level digest functions\n\nUse of low-level digest functions such as SHA1Init(3) have been informally discouraged from\nuse for a long time. Applications should instead use the the high level EVP APIs\nEVPDigestInitex(3), EVPDigestUpdate(3) and EVPDigestFinalex(3), or the quick one-shot\nEVPQdigest(3).\n\nNote that the functions SHA1(3), SHA224(3), SHA256(3), SHA384(3) and SHA512(3) have changed\nto macros that use EVPQdigest(3).\n\nDeprecated low-level signing functions\n\nUse of low-level signing functions such as DSAsign(3) have been informally discouraged for a\nlong time. Instead applications should use EVPDigestSign(3) and EVPDigestVerify(3). See\nalso EVPSIGNATURE-RSA(7), EVPSIGNATURE-DSA(7), EVPSIGNATURE-ECDSA(7) and\nEVPSIGNATURE-ED25519(7).\n\nDeprecated low-level MAC functions\n\nLow-level mac functions such as CMACInit(3) are deprecated. Applications should instead use\nthe new EVPMAC(3) interface, using EVPMACCTXnew(3), EVPMACCTXfree(3), EVPMACinit(3),\nEVPMACupdate(3) and EVPMACfinal(3) or the single-shot MAC function EVPQmac(3). See\nEVPMAC(3), EVPMAC-HMAC(7), EVPMAC-CMAC(7), EVPMAC-GMAC(7), EVPMAC-KMAC(7),\nEVPMAC-BLAKE2(7), EVPMAC-Poly1305(7) and EVPMAC-Siphash(7) for additional information.\n\nNote that the one-shot method HMAC() is still available for compatibility purposes, but this\ncan also be replaced by using EVPQMAC if a library context is required.\n\nDeprecated low-level validation functions\n\nLow-level validation functions such as DHcheck(3) have been informally discouraged from use\nfor a long time. Applications should instead use the high-level EVPPKEY APIs such as\nEVPPKEYcheck(3), EVPPKEYparamcheck(3), EVPPKEYparamcheckquick(3),\nEVPPKEYpubliccheck(3), EVPPKEYpubliccheckquick(3), EVPPKEYprivatecheck(3), and\nEVPPKEYpairwisecheck(3).\n\nDeprecated low-level key exchange functions\n\nMany low-level functions have been informally discouraged from use for a long time.\nApplications should instead use EVPPKEYderive(3). See EVPKEYEXCH-DH(7),\nEVPKEYEXCH-ECDH(7) and EVPKEYEXCH-X25519(7).\n\nDeprecated low-level key generation functions\n\nMany low-level functions have been informally discouraged from use for a long time.\nApplications should instead use EVPPKEYkeygeninit(3) and EVPPKEYgenerate(3) as described\nin EVPPKEY-DSA(7), EVPPKEY-DH(7), EVPPKEY-RSA(7), EVPPKEY-EC(7) and EVPPKEY-X25519(7).\nThe 'quick' one-shot function EVPPKEYQkeygen(3) and macros for the most common cases:\n and EVPECgen(3) may also be used.\n\nDeprecated low-level key reading and writing functions\n\nUse of low-level objects (such as DSA) has been informally discouraged from use for a long\ntime. Functions to read and write these low-level objects (such as PEMreadDSAPUBKEY())\nshould be replaced. Applications should instead use OSSLENCODERtobio(3) and\nOSSLDECODERfrombio(3).\n\nDeprecated low-level key printing functions\n\nUse of low-level objects (such as DSA) has been informally discouraged from use for a long\ntime. Functions to print these low-level objects such as DSAprint() should be replaced with\nthe equivalent EVPPKEY functions. Application should use one of EVPPKEYprintpublic(3),\nEVPPKEYprintprivate(3), EVPPKEYprintparams(3), EVPPKEYprintpublicfp(3),\nEVPPKEYprintprivatefp(3) or EVPPKEYprintparamsfp(3). Note that internally these use\nOSSLENCODERtobio(3) and OSSLDECODERfrombio(3).\n\nDeprecated function mappings\n\nThe following functions have been deprecated in 3.0.\n\n• AESbiigeencrypt() and AESigeencrypt()\n\nThere is no replacement for the IGE functions. New code should not use these modes.\nThese undocumented functions were never integrated into the EVP layer. They implemented\nthe AES Infinite Garble Extension (IGE) mode and AES Bi-directional IGE mode. These modes\nwere never formally standardised and usage of these functions is believed to be very\nsmall. In particular AESbiigeencrypt() has a known bug. It accepts 2 AES keys, but\nonly one is ever used. The security implications are believed to be minimal, but this\nissue was never fixed for backwards compatibility reasons.\n\n• AESencrypt(), AESdecrypt(), AESsetencryptkey(), AESsetdecryptkey(),\nAEScbcencrypt(), AEScfb128encrypt(), AEScfb1encrypt(), AEScfb8encrypt(),\nAESecbencrypt(), AESofb128encrypt()\n\n• AESunwrapkey(), AESwrapkey()\n\nSee \"Deprecated low-level encryption functions\"\n\n• AESoptions()\n\nThere is no replacement. It returned a string indicating if the AES code was unrolled.\n\n• ASN1digest(), ASN1sign(), ASN1verify()\n\nThere are no replacements. These old functions are not used, and could be disabled with\nthe macro NOASN1OLD since OpenSSL 0.9.7.\n\n• ASN1STRINGlengthset()\n\nUse ASN1STRINGset(3) or ASN1STRINGset0(3) instead. This was a potentially unsafe\nfunction that could change the bounds of a previously passed in pointer.\n\n• BFencrypt(), BFdecrypt(), BFsetkey(), BFcbcencrypt(), BFcfb64encrypt(),\nBFecbencrypt(), BFofb64encrypt()\n\nSee \"Deprecated low-level encryption functions\". The Blowfish algorithm has been moved\nto the Legacy Provider.\n\n• BFoptions()\n\nThere is no replacement. This option returned a constant string.\n\n• BIOgetcallback(), BIOsetcallback(), BIOdebugcallback()\n\nUse the respective non-deprecated ex() functions.\n\n• BNisprimeex(), BNisprimefasttestex()\n\nUse BNcheckprime(3) which avoids possible misuse and always uses at least 64 rounds of\nthe Miller-Rabin primality test.\n\n• BNpseudorand(), BNpseudorandrange()\n\nUse BNrand(3) and BNrandrange(3).\n\n• BNX931deriveprimeex(), BNX931generateprimeex(), BNX931generateXpq()\n\nThere are no replacements for these low-level functions. They were used internally by\nRSAX931deriveex() and RSAX931generatekeyex() which are also deprecated. Use\nEVPPKEYkeygen(3) instead.\n\n• Camelliaencrypt(), Camelliadecrypt(), Camelliasetkey(), Camelliacbcencrypt(),\nCamelliacfb128encrypt(), Camelliacfb1encrypt(), Camelliacfb8encrypt(),\nCamelliactr128encrypt(), Camelliaecbencrypt(), Camelliaofb128encrypt()\n\nSee \"Deprecated low-level encryption functions\".\n\n• CASTencrypt(), CASTdecrypt(), CASTsetkey(), CASTcbcencrypt(), CASTcfb64encrypt(),\nCASTecbencrypt(), CASTofb64encrypt()\n\nSee \"Deprecated low-level encryption functions\". The CAST algorithm has been moved to\nthe Legacy Provider.\n\n• CMACCTXnew(), CMACCTXcleanup(), CMACCTXcopy(), CMACCTXfree(),\nCMACCTXget0cipherctx()\n\nSee \"Deprecated low-level MAC functions\".\n\n• CMACInit(), CMACUpdate(), CMACFinal(), CMACresume()\n\nSee \"Deprecated low-level MAC functions\".\n\n• CRYPTOmemctrl(), CRYPTOmemdebugfree(), CRYPTOmemdebugmalloc(),\nCRYPTOmemdebugpop(), CRYPTOmemdebugpush(), CRYPTOmemdebugrealloc(),\nCRYPTOmemleaks(), CRYPTOmemleakscb(), CRYPTOmemleaksfp(), CRYPTOsetmemdebug()\n\nMemory-leak checking has been deprecated in favor of more modern development tools, such\nas compiler memory and leak sanitizers or Valgrind.\n\n• CRYPTOcts128encryptblock(), CRYPTOcts128encrypt(), CRYPTOcts128decryptblock(),\nCRYPTOcts128decrypt(), CRYPTOnistcts128encryptblock(), CRYPTOnistcts128encrypt(),\nCRYPTOnistcts128decryptblock(), CRYPTOnistcts128decrypt()\n\nUse the higher level functions EVPCipherInitex2(), EVPCipherUpdate() and\nEVPCipherFinalex() instead. See the \"ctsmode\" parameter in \"Gettable and Settable\nEVPCIPHERCTX parameters\" in EVPEncryptInit(3). See \"EXAMPLES\" in EVPEncryptInit(3)\nfor a AES-256-CBC-CTS example.\n\n• d2iDHparams(), d2iDHxparams(), d2iDSAparams(), d2iDSAPrivateKey(),\nd2iDSAPrivateKeybio(), d2iDSAPrivateKeyfp(), d2iDSAPUBKEY(), d2iDSAPUBKEYbio(),\nd2iDSAPUBKEYfp(), d2iDSAPublicKey(), d2iECParameters(), d2iECPrivateKey(),\nd2iECPrivateKeybio(), d2iECPrivateKeyfp(), d2iECPUBKEY(), d2iECPUBKEYbio(),\nd2iECPUBKEYfp(), o2iECPublicKey(), d2iRSAPrivateKey(), d2iRSAPrivateKeybio(),\nd2iRSAPrivateKeyfp(), d2iRSAPUBKEY(), d2iRSAPUBKEYbio(), d2iRSAPUBKEYfp(),\nd2iRSAPublicKey(), d2iRSAPublicKeybio(), d2iRSAPublicKeyfp()\n\nSee \"Deprecated i2d and d2i functions for low-level key types\"\n\n• DEScrypt(), DESfcrypt(), DESencrypt1(), DESencrypt2(), DESencrypt3(),\nDESdecrypt3(), DESede3cbcencrypt(), DESede3cfb64encrypt(),\nDESede3cfbencrypt(),DESede3ofb64encrypt(), DESecbencrypt(), DESecb3encrypt(),\nDESofb64encrypt(), DESofbencrypt(), DEScfb64encrypt DEScfbencrypt(),\nDEScbcencrypt(), DESncbcencrypt(), DESpcbcencrypt(), DESxcbcencrypt(),\nDEScbccksum(), DESquadcksum(), DEScheckkeyparity(), DESisweakkey(),\nDESkeysched(), DESoptions(), DESrandomkey(), DESsetkey(), DESsetkeychecked(),\nDESsetkeyunchecked(), DESsetoddparity(), DESstringto2keys(), DESstringtokey()\n\nSee \"Deprecated low-level encryption functions\". Algorithms for \"DESX-CBC\", \"DES-ECB\",\n\"DES-CBC\", \"DES-OFB\", \"DES-CFB\", \"DES-CFB1\" and \"DES-CFB8\" have been moved to the Legacy\nProvider.\n\n• DHbits(), DHsecuritybits(), DHsize()\n\nUse EVPPKEYgetbits(3), EVPPKEYgetsecuritybits(3) and EVPPKEYgetsize(3).\n\n• DHcheck(), DHcheckex(), DHcheckparams(), DHcheckparamsex(), DHcheckpubkey(),\nDHcheckpubkeyex()\n\nSee \"Deprecated low-level validation functions\"\n\n• DHclearflags(), DHtestflags(), DHsetflags()\n\nThe DHFLAGCACHEMONTP flag has been deprecated without replacement. The\nDHFLAGTYPEDH and DHFLAGTYPEDHX have been deprecated. Use EVPPKEYisa() to\ndetermine the type of a key. There is no replacement for setting these flags.\n\n• DHcomputekey() DHcomputekeypadded()\n\nSee \"Deprecated low-level key exchange functions\".\n\n• DHnew(), DHnewbynid(), DHfree(), DHupref()\n\nSee \"Deprecated low-level object creation\"\n\n• DHgeneratekey(), DHgenerateparametersex()\n\nSee \"Deprecated low-level key generation functions\".\n\n• DHget0pqg(), DHget0p(), DHget0q(), DHget0g(), DHget0key(), DHget0privkey(),\nDHget0pubkey(), DHgetlength(), DHgetnid()\n\nSee \"Deprecated low-level key parameter getters\"\n\n• DHget1024160(), DHget2048224(), DHget2048256()\n\nApplications should instead set the OSSLPKEYPARAMGROUPNAME as specified in \"DH\nparameters\" in EVPPKEY-DH(7)) to one of \"dh1024160\", \"dh2048224\" or \"dh2048256\"\nwhen generating a DH key.\n\n• DHKDFX942()\n\nApplications should use EVPPKEYCTXsetdhkdftype(3) instead.\n\n• DHgetdefaultmethod(), DHget0engine(), DHmeth*(), DHnewmethod(), DHOpenSSL(),\nDHgetexdata(), DHsetdefaultmethod(), DHsetmethod(), DHsetexdata()\n\nSee \"Providers are a replacement for engines and low-level method overrides\"\n\n• DHparamsprint(), DHparamsprintfp()\n\nSee \"Deprecated low-level key printing functions\"\n\n• DHset0key(), DHset0pqg(), DHsetlength()\n\nSee \"Deprecated low-level key parameter setters\"\n\n• DSAbits(), DSAsecuritybits(), DSAsize()\n\nUse EVPPKEYgetbits(3), EVPPKEYgetsecuritybits(3) and EVPPKEYgetsize(3).\n\n• DHparamsdup(), DSAdupDH()\n\nThere is no direct replacement. Applications may use EVPPKEYcopyparameters(3) and\nEVPPKEYdup(3) instead.\n\n• DSAgeneratekey(), DSAgenerateparametersex()\n\nSee \"Deprecated low-level key generation functions\".\n\n• DSAget0engine(), DSAgetdefaultmethod(), DSAgetexdata(), DSAgetmethod(),\nDSAmeth*(), DSAnewmethod(), DSAOpenSSL(), DSAsetdefaultmethod(),\nDSAsetexdata(), DSAsetmethod()\n\nSee \"Providers are a replacement for engines and low-level method overrides\".\n\n• DSAget0p(), DSAget0q(), DSAget0g(), DSAget0pqg(), DSAget0key(),\nDSAget0privkey(), DSAget0pubkey()\n\nSee \"Deprecated low-level key parameter getters\".\n\n• DSAnew(), DSAfree(), DSAupref()\n\nSee \"Deprecated low-level object creation\"\n\n• DSAparamsdup()\n\nThere is no direct replacement. Applications may use EVPPKEYcopyparameters(3) and\nEVPPKEYdup(3) instead.\n\n• DSAparamsprint(), DSAparamsprintfp(), DSAprint(), DSAprintfp()\n\nSee \"Deprecated low-level key printing functions\"\n\n• DSAset0key(), DSAset0pqg()\n\nSee \"Deprecated low-level key parameter setters\"\n\n• DSAsetflags(), DSAclearflags(), DSAtestflags()\n\nThe DSAFLAGCACHEMONTP flag has been deprecated without replacement.\n\n• DSAsign(), DSAdosign(), DSAsignsetup(), DSAverify(), DSAdoverify()\n\nSee \"Deprecated low-level signing functions\".\n\n• ECDHcomputekey()\n\nSee \"Deprecated low-level key exchange functions\".\n\n• ECDHKDFX962()\n\nApplications may either set this using the helper function\nEVPPKEYCTXsetecdhkdftype(3) or by setting an OSSLPARAM(3) using the \"kdf-type\" as\nshown in \"EXAMPLES\" in EVPKEYEXCH-ECDH(7)\n\n• ECDSAsign(), ECDSAsignex(), ECDSAsignsetup(), ECDSAdosign(), ECDSAdosignex(),\nECDSAverify(), ECDSAdoverify()\n\nSee \"Deprecated low-level signing functions\".\n\n• ECDSAsize()\n\nApplications should use EVPPKEYgetsize(3).\n\n• ECGF2msimplemethod(), ECGFpmontmethod(), ECGFpnistmethod(),\nECGFpnistp224method(), ECGFpnistp256method(), ECGFpnistp521method(),\nECGFpsimplemethod()\n\nThere are no replacements for these functions. Applications should rely on the library\nautomatically assigning a suitable method internally when an ECGROUP is constructed.\n\n• ECGROUPclearfree()\n\nUse ECGROUPfree(3) instead.\n\n• ECGROUPgetcurveGF2m(), ECGROUPgetcurveGFp(), ECGROUPsetcurveGF2m(),\nECGROUPsetcurveGFp()\n\nApplications should use ECGROUPgetcurve(3) and ECGROUPsetcurve(3).\n\n• ECGROUPhaveprecomputemult(), ECGROUPprecomputemult(), ECKEYprecomputemult()\n\nThese functions are not widely used. Applications should instead switch to named curves\nwhich OpenSSL has hardcoded lookup tables for.\n\n• ECGROUPnew(), ECGROUPmethodof(), ECPOINTmethodof()\n\nECMETHOD is now an internal-only concept and a suitable ECMETHOD is assigned internally\nwithout application intervention. Users of ECGROUPnew() should switch to a different\nsuitable constructor.\n\n• ECKEYcansign()\n\nApplications should use EVPPKEYcansign(3) instead.\n\n• ECKEYcheckkey()\n\nSee \"Deprecated low-level validation functions\"\n\n• ECKEYsetflags(), ECKEYgetflags(), ECKEYclearflags()\n\nSee \"Common EC parameters\" in EVPPKEY-EC(7) which handles flags as separate parameters\nfor OSSLPKEYPARAMECPOINTCONVERSIONFORMAT, OSSLPKEYPARAMECGROUPCHECKTYPE,\nOSSLPKEYPARAMECENCODING, OSSLPKEYPARAMUSECOFACTORECDH and\nOSSLPKEYPARAMECINCLUDEPUBLIC. See also \"EXAMPLES\" in EVPPKEY-EC(7)\n\n• ECKEYdup(), ECKEYcopy()\n\nThere is no direct replacement. Applications may use EVPPKEYcopyparameters(3) and\nEVPPKEYdup(3) instead.\n\n• ECKEYdecodedfromexplicitparams()\n\nThere is no replacement.\n\n• ECKEYgeneratekey()\n\nSee \"Deprecated low-level key generation functions\".\n\n• ECKEYget0group(), ECKEYget0privatekey(), ECKEYget0publickey(),\nECKEYgetconvform(), ECKEYgetencflags()\n\nSee \"Deprecated low-level key parameter getters\".\n\n• ECKEYget0engine(), ECKEYgetdefaultmethod(), ECKEYgetmethod(),\nECKEYnewmethod(), ECKEYgetexdata(), ECKEYOpenSSL(), ECKEYsetexdata(),\nECKEYsetdefaultmethod(), ECKEYMETHOD*(), ECKEYsetmethod()\n\nSee \"Providers are a replacement for engines and low-level method overrides\"\n\n• ECMETHODgetfieldtype()\n\nUse ECGROUPgetfieldtype(3) instead. See \"Providers are a replacement for engines and\nlow-level method overrides\"\n\n• ECKEYkey2buf(), ECKEYoct2key(), ECKEYoct2priv(), ECKEYpriv2buf(),\nECKEYpriv2oct()\n\nThere are no replacements for these.\n\n• ECKEYnew(), ECKEYnewbycurvename(), ECKEYfree(), ECKEYupref()\n\nSee \"Deprecated low-level object creation\"\n\n• ECKEYprint(), ECKEYprintfp()\n\nSee \"Deprecated low-level key printing functions\"\n\n• ECKEYsetasn1flag(), ECKEYsetconvform(), ECKEYsetencflags()\n\nSee \"Deprecated low-level key parameter setters\".\n\n• ECKEYsetgroup(), ECKEYsetprivatekey(), ECKEYsetpublickey(),\nECKEYsetpublickeyaffinecoordinates()\n\nSee \"Deprecated low-level key parameter setters\".\n\n• ECParametersprint(), ECParametersprintfp(), ECPKParametersprint(),\nECPKParametersprintfp()\n\nSee \"Deprecated low-level key printing functions\"\n\n• ECPOINTbn2point(), ECPOINTpoint2bn()\n\nThese functions were not particularly useful, since EC point serialization formats are\nnot individual big-endian integers.\n\n• ECPOINTgetaffinecoordinatesGF2m(), ECPOINTgetaffinecoordinatesGFp(),\nECPOINTsetaffinecoordinatesGF2m(), ECPOINTsetaffinecoordinatesGFp()\n\nApplications should use ECPOINTgetaffinecoordinates(3) and\nECPOINTsetaffinecoordinates(3) instead.\n\n• ECPOINTgetJprojectivecoordinatesGFp(), ECPOINTsetJprojectivecoordinatesGFp()\n\nThese functions are not widely used. Applications should instead use the\nECPOINTsetaffinecoordinates(3) and ECPOINTgetaffinecoordinates(3) functions.\n\n• ECPOINTmakeaffine(), ECPOINTsmakeaffine()\n\nThere is no replacement. These functions were not widely used, and OpenSSL automatically\nperforms this conversion when needed.\n\n• ECPOINTsetcompressedcoordinatesGF2m(), ECPOINTsetcompressedcoordinatesGFp()\n\nApplications should use ECPOINTsetcompressedcoordinates(3) instead.\n\n• ECPOINTsmul()\n\nThis function is not widely used. Applications should instead use the ECPOINTmul(3)\nfunction.\n\n• ENGINE*()\n\nAll engine functions are deprecated. An engine should be rewritten as a provider. See\n\"Providers are a replacement for engines and low-level method overrides\".\n\n• ERRload*(), ERRfuncerrorstring(), ERRgeterrorline(), ERRgeterrorlinedata(),\nERRgetstate()\n\nOpenSSL now loads error strings automatically so these functions are not needed.\n\n• ERRpeekerrorlinedata(), ERRpeeklasterrorlinedata()\n\nThe new functions are ERRpeekerrorfunc(3), ERRpeeklasterrorfunc(3),\nERRpeekerrordata(3), ERRpeeklasterrordata(3), ERRgeterrorall(3),\nERRpeekerrorall(3) and ERRpeeklasterrorall(3). Applications should use\nERRgeterrorall(3), or pick information with ERRpeek functions and finish off with\ngetting the error code by using ERRgeterror(3).\n\n• EVPCIPHERCTXiv(), EVPCIPHERCTXivnoconst(), EVPCIPHERCTXoriginaliv()\n\nApplications should instead use EVPCIPHERCTXgetupdatediv(3),\nEVPCIPHERCTXgetupdatediv(3) and EVPCIPHERCTXgetoriginaliv(3) respectively. See\nEVPCIPHERCTXgetoriginaliv(3) for further information.\n\n• EVPCIPHERmeth*(), EVPMDCTXsetupdatefn(), EVPMDCTXupdatefn(), EVPMDmeth*()\n\nSee \"Providers are a replacement for engines and low-level method overrides\".\n\n• EVPPKEYCTRLPKCS7ENCRYPT(), EVPPKEYCTRLPKCS7DECRYPT(), EVPPKEYCTRLPKCS7SIGN(),\nEVPPKEYCTRLCMSENCRYPT(), EVPPKEYCTRLCMSDECRYPT(), and EVPPKEYCTRLCMSSIGN()\n\nThese control operations are not invoked by the OpenSSL library anymore and are replaced\nby direct checks of the key operation against the key type when the operation is\ninitialized.\n\n• EVPPKEYCTXget0dhkdfukm(), EVPPKEYCTXget0ecdhkdfukm()\n\nSee the \"kdf-ukm\" item in \"DH key exchange parameters\" in EVPKEYEXCH-DH(7) and \"ECDH Key\nExchange parameters\" in EVPKEYEXCH-ECDH(7). These functions are obsolete and should not\nbe required.\n\n• EVPPKEYCTXsetrsakeygenpubexp()\n\nApplications should use EVPPKEYCTXset1rsakeygenpubexp(3) instead.\n\n• EVPPKEYcmp(), EVPPKEYcmpparameters()\n\nApplications should use EVPPKEYeq(3) and EVPPKEYparameterseq(3) instead. See\nEVPPKEYcopyparameters(3) for further details.\n\n• EVPPKEYencryptold(), EVPPKEYdecryptold(),\n\nApplications should use EVPPKEYencryptinit(3) and EVPPKEYencrypt(3) or\nEVPPKEYdecryptinit(3) and EVPPKEYdecrypt(3) instead.\n\n• EVPPKEYget0()\n\nThis function returns NULL if the key comes from a provider.\n\n• EVPPKEYget0DH(), EVPPKEYget0DSA(), EVPPKEYget0ECKEY(), EVPPKEYget0RSA(),\nEVPPKEYget1DH(), EVPPKEYget1DSA(), EVPPKEYget1ECKEY and EVPPKEYget1RSA(),\nEVPPKEYget0hmac(), EVPPKEYget0poly1305(), EVPPKEYget0siphash()\n\nSee \"Functions that return an internal key should be treated as read only\".\n\n• EVPPKEYmeth*()\n\nSee \"Providers are a replacement for engines and low-level method overrides\".\n\n• EVPPKEYnewCMACkey()\n\nSee \"Deprecated low-level MAC functions\".\n\n• EVPPKEYassign(), EVPPKEYset1DH(), EVPPKEYset1DSA(), EVPPKEYset1ECKEY(),\nEVPPKEYset1RSA()\n\nSee \"Deprecated low-level key object getters and setters\"\n\n• EVPPKEYset1tlsencodedpoint() EVPPKEYget1tlsencodedpoint()\n\nThese functions were previously used by libssl to set or get an encoded public key\ninto/from an EVPPKEY object. With OpenSSL 3.0 these are replaced by the more generic\nfunctions EVPPKEYset1encodedpublickey(3) and EVPPKEYget1encodedpublickey(3).\nThe old versions have been converted to deprecated macros that just call the new\nfunctions.\n\n• EVPPKEYset1engine(), EVPPKEYget0engine()\n\nSee \"Providers are a replacement for engines and low-level method overrides\".\n\n• EVPPKEYsetaliastype()\n\nThis function has been removed. There is no replacement. See \"EVPPKEYsetaliastype()\nmethod has been removed\"\n\n• HMACInitex(), HMACUpdate(), HMACFinal(), HMACsize()\n\nSee \"Deprecated low-level MAC functions\".\n\n• HMACCTXnew(), HMACCTXfree(), HMACCTXcopy(), HMACCTXreset(), HMACCTXsetflags(),\nHMACCTXgetmd()\n\nSee \"Deprecated low-level MAC functions\".\n\n• i2dDHparams(), i2dDHxparams()\n\nSee \"Deprecated low-level key reading and writing functions\" and \"Migration\" in\nd2iRSAPrivateKey(3)\n\n• i2dDSAparams(), i2dDSAPrivateKey(), i2dDSAPrivateKeybio(), i2dDSAPrivateKeyfp(),\ni2dDSAPUBKEY(), i2dDSAPUBKEYbio(), i2dDSAPUBKEYfp(), i2dDSAPublicKey()\n\nSee \"Deprecated low-level key reading and writing functions\" and \"Migration\" in\nd2iRSAPrivateKey(3)\n\n• i2dECParameters(), i2dECPrivateKey(), i2dECPrivateKeybio(), i2dECPrivateKeyfp(),\ni2dECPUBKEY(), i2dECPUBKEYbio(), i2dECPUBKEYfp(), i2oECPublicKey()\n\nSee \"Deprecated low-level key reading and writing functions\" and \"Migration\" in\nd2iRSAPrivateKey(3)\n\n• i2dRSAPrivateKey(), i2dRSAPrivateKeybio(), i2dRSAPrivateKeyfp(), i2dRSAPUBKEY(),\ni2dRSAPUBKEYbio(), i2dRSAPUBKEYfp(), i2dRSAPublicKey(), i2dRSAPublicKeybio(),\ni2dRSAPublicKeyfp()\n\nSee \"Deprecated low-level key reading and writing functions\" and \"Migration\" in\nd2iRSAPrivateKey(3)\n\n• IDEAencrypt(), IDEAsetdecryptkey(), IDEAsetencryptkey(), IDEAcbcencrypt(),\nIDEAcfb64encrypt(), IDEAecbencrypt(), IDEAofb64encrypt()\n\nSee \"Deprecated low-level encryption functions\". IDEA has been moved to the Legacy\nProvider.\n\n• IDEAoptions()\n\nThere is no replacement. This function returned a constant string.\n\n• MD2(), MD2Init(), MD2Update(), MD2Final()\n\nSee \"Deprecated low-level encryption functions\". MD2 has been moved to the Legacy\nProvider.\n\n• MD2options()\n\nThere is no replacement. This function returned a constant string.\n\n• MD4(), MD4Init(), MD4Update(), MD4Final(), MD4Transform()\n\nSee \"Deprecated low-level encryption functions\". MD4 has been moved to the Legacy\nProvider.\n\n• MDC2(), MDC2Init(), MDC2Update(), MDC2Final()\n\nSee \"Deprecated low-level encryption functions\". MDC2 has been moved to the Legacy\nProvider.\n\n• MD5(), MD5Init(), MD5Update(), MD5Final(), MD5Transform()\n\nSee \"Deprecated low-level encryption functions\".\n\n• NCONFWIN32()\n\nThis undocumented function has no replacement. See \"HISTORY\" in config(5) for more\ndetails.\n\n• OCSPparseurl()\n\nUse OSSLHTTPparseurl(3) instead.\n\n• OCSPREQCTX type and OCSPREQCTX*() functions\n\nThese methods were used to collect all necessary data to form a HTTP request, and to\nperform the HTTP transfer with that request. With OpenSSL 3.0, the type is\nOSSLHTTPREQCTX, and the deprecated functions are replaced with OSSLHTTPREQCTX*().\nSee OSSLHTTPREQCTX(3) for additional details.\n\n• OPENSSLforkchild(), OPENSSLforkparent(), OPENSSLforkprepare()\n\nThere is no replacement for these functions. These pthread fork support methods were\nunused by OpenSSL.\n\n• OSSLSTOREctrl(), OSSLSTOREdoallloaders(), OSSLSTORELOADERget0engine(),\nOSSLSTORELOADERget0scheme(), OSSLSTORELOADERnew(), OSSLSTORELOADERsetattach(),\nOSSLSTORELOADERsetclose(), OSSLSTORELOADERsetctrl(), OSSLSTORELOADERseteof(),\nOSSLSTORELOADERseterror(), OSSLSTORELOADERsetexpect(),\nOSSLSTORELOADERsetfind(), OSSLSTORELOADERsetload(), OSSLSTORELOADERsetopen(),\nOSSLSTORELOADERsetopenex(), OSSLSTOREregisterloader(),\nOSSLSTOREunregisterloader(), OSSLSTOREvctrl()\n\nThese functions helped applications and engines create loaders for schemes they\nsupported. These are all deprecated and discouraged in favour of provider\nimplementations, see provider-storemgmt(7).\n\n• PEMreadDHparams(), PEMreadbioDHparams(), PEMreadDSAparams(),\nPEMreadbioDSAparams(), PEMreadDSAPrivateKey(), PEMreadDSAPUBKEY(),\nPEMreadbioDSAPrivateKey and PEMreadbioDSAPUBKEY(), PEMreadECPKParameters(),\nPEMreadECPrivateKey(), PEMreadECPUBKEY(), PEMreadbioECPKParameters(),\nPEMreadbioECPrivateKey(), PEMreadbioECPUBKEY(), PEMreadRSAPrivateKey(),\nPEMreadRSAPUBKEY(), PEMreadRSAPublicKey(), PEMreadbioRSAPrivateKey(),\nPEMreadbioRSAPUBKEY(), PEMreadbioRSAPublicKey(), PEMwritebioDHparams(),\nPEMwritebioDHxparams(), PEMwriteDHparams(), PEMwriteDHxparams(),\nPEMwriteDSAparams(), PEMwriteDSAPrivateKey(), PEMwriteDSAPUBKEY(),\nPEMwritebioDSAparams(), PEMwritebioDSAPrivateKey(), PEMwritebioDSAPUBKEY(),\nPEMwriteECPKParameters(), PEMwriteECPrivateKey(), PEMwriteECPUBKEY(),\nPEMwritebioECPKParameters(), PEMwritebioECPrivateKey(), PEMwritebioECPUBKEY(),\nPEMwriteRSAPrivateKey(), PEMwriteRSAPUBKEY(), PEMwriteRSAPublicKey(),\nPEMwritebioRSAPrivateKey(), PEMwritebioRSAPUBKEY(), PEMwritebioRSAPublicKey(),\n\nSee \"Deprecated low-level key reading and writing functions\"\n\n• PKCS1MGF1()\n\nSee \"Deprecated low-level encryption functions\".\n\n• RANDgetrandmethod(), RANDsetrandmethod(), RANDOpenSSL(), RANDsetrandengine()\n\nApplications should instead use RANDsetDRBGtype(3), EVPRAND(3) and EVPRAND(7). See\nRANDsetrandmethod(3) for more details.\n\n• RC2encrypt(), RC2decrypt(), RC2setkey(), RC2cbcencrypt(), RC2cfb64encrypt(),\nRC2ecbencrypt(), RC2ofb64encrypt(), RC4(), RC4setkey(), RC4options(),\nRC532encrypt(), RC532setkey(), RC532decrypt(), RC532cbcencrypt(),\nRC532cfb64encrypt(), RC532ecbencrypt(), RC532ofb64encrypt()\n\nSee \"Deprecated low-level encryption functions\". The Algorithms \"RC2\", \"RC4\" and \"RC5\"\nhave been moved to the Legacy Provider.\n\n• RIPEMD160(), RIPEMD160Init(), RIPEMD160Update(), RIPEMD160Final(),\nRIPEMD160Transform()\n\nSee \"Deprecated low-level digest functions\". The RIPE algorithm has been moved to the\nLegacy Provider.\n\n• RSAbits(), RSAsecuritybits(), RSAsize()\n\nUse EVPPKEYgetbits(3), EVPPKEYgetsecuritybits(3) and EVPPKEYgetsize(3).\n\n• RSAcheckkey(), RSAcheckkeyex()\n\nSee \"Deprecated low-level validation functions\"\n\n• RSAclearflags(), RSAflags(), RSAsetflags(), RSAtestflags(), RSAsetupblinding(),\nRSAblindingoff(), RSAblindingon()\n\nAll of these RSA flags have been deprecated without replacement:\n\nRSAFLAGBLINDING, RSAFLAGCACHEPRIVATE, RSAFLAGCACHEPUBLIC, RSAFLAGEXTPKEY,\nRSAFLAGNOBLINDING, RSAFLAGTHREADSAFE RSAMETHODFLAGNOCHECK\n\n• RSAgeneratekeyex(), RSAgeneratemultiprimekey()\n\nSee \"Deprecated low-level key generation functions\".\n\n• RSAget0engine()\n\nSee \"Providers are a replacement for engines and low-level method overrides\"\n\n• RSAget0crtparams(), RSAget0d(), RSAget0dmp1(), RSAget0dmq1(), RSAget0e(),\nRSAget0factors(), RSAget0iqmp(), RSAget0key(), RSAget0multiprimecrtparams(),\nRSAget0multiprimefactors(), RSAget0n(), RSAget0p(), RSAget0pssparams(),\nRSAget0q(), RSAgetmultiprimeextracount()\n\nSee \"Deprecated low-level key parameter getters\"\n\n• RSAnew(), RSAfree(), RSAupref()\n\nSee \"Deprecated low-level object creation\".\n\n• RSAgetdefaultmethod(), RSAgetexdata and RSAgetmethod()\n\nSee \"Providers are a replacement for engines and low-level method overrides\".\n\n• RSAgetversion()\n\nThere is no replacement.\n\n• RSAmeth*(), RSAnewmethod(), RSAnullmethod and RSAPKCS1OpenSSL()\n\nSee \"Providers are a replacement for engines and low-level method overrides\".\n\n• RSApaddingadd*(), RSApaddingcheck*()\n\nSee \"Deprecated low-level signing functions\" and \"Deprecated low-level encryption\nfunctions\".\n\n• RSAprint(), RSAprintfp()\n\nSee \"Deprecated low-level key printing functions\"\n\n• RSApublicencrypt(), RSAprivatedecrypt()\n\nSee \"Deprecated low-level encryption functions\"\n\n• RSAprivateencrypt(), RSApublicdecrypt()\n\nThis is equivalent to doing sign and verify recover operations (with a padding mode of\nnone). See \"Deprecated low-level signing functions\".\n\n• RSAPrivateKeydup(), RSAPublicKeydup()\n\nThere is no direct replacement. Applications may use EVPPKEYdup(3).\n\n• RSAPublicKeyit(), RSAPrivateKeyit()\n\nSee \"Deprecated low-level key reading and writing functions\"\n\n• RSAset0crtparams(), RSAset0factors(), RSAset0key(), RSAset0multiprimeparams()\n\nSee \"Deprecated low-level key parameter setters\".\n\n• RSAsetdefaultmethod(), RSAsetmethod(), RSAsetexdata()\n\nSee \"Providers are a replacement for engines and low-level method overrides\"\n\n• RSAsign(), RSAsignASN1OCTETSTRING(), RSAverify(), RSAverifyASN1OCTETSTRING(),\nRSAverifyPKCS1PSS(), RSAverifyPKCS1PSSmgf1()\n\nSee \"Deprecated low-level signing functions\".\n\n• RSAX931deriveex(), RSAX931generatekeyex(), RSAX931hashid()\n\nThere are no replacements for these functions. X931 padding can be set using \"Signature\nParameters\" in EVPSIGNATURE-RSA(7). See OSSLSIGNATUREPARAMPADMODE.\n\n• SEEDencrypt(), SEEDdecrypt(), SEEDsetkey(), SEEDcbcencrypt(),\nSEEDcfb128encrypt(), SEEDecbencrypt(), SEEDofb128encrypt()\n\nSee \"Deprecated low-level encryption functions\". The SEED algorithm has been moved to\nthe Legacy Provider.\n\n• SHA1Init(), SHA1Update(), SHA1Final(), SHA1Transform(), SHA224Init(),\nSHA224Update(), SHA224Final(), SHA256Init(), SHA256Update(), SHA256Final(),\nSHA256Transform(), SHA384Init(), SHA384Update(), SHA384Final(), SHA512Init(),\nSHA512Update(), SHA512Final(), SHA512Transform()\n\nSee \"Deprecated low-level digest functions\".\n\n• SRPCalcA(), SRPCalcB(), SRPCalcclientkey(), SRPCalcserverkey(), SRPCalcu(),\nSRPCalcx(), SRPcheckknowngNparam(), SRPcreateverifier(),\nSRPcreateverifierBN(), SRPgetdefaultgN(), SRPuserpwdfree(), SRPuserpwdnew(),\nSRPuserpwdset0sv(), SRPuserpwdset1ids(), SRPuserpwdsetgN(),\nSRPVBASEadd0user(), SRPVBASEfree(), SRPVBASEget1byuser(), SRPVBASEinit(),\nSRPVBASEnew(), SRPVerifyAmodN(), SRPVerifyBmodN()\n\nThere are no replacements for the SRP functions.\n\n• SSLCTXsettmpdhcallback(), SSLsettmpdhcallback(), SSLCTXsettmpdh(),\nSSLsettmpdh()\n\nThese are used to set the Diffie-Hellman (DH) parameters that are to be used by servers\nrequiring ephemeral DH keys. Instead applications should consider using the built-in DH\nparameters that are available by calling SSLCTXsetdhauto(3) or SSLsetdhauto(3). If\ncustom parameters are necessary then applications can use the alternative functions\nSSLCTXset0tmpdhpkey(3) and SSLset0tmpdhpkey(3). There is no direct replacement\nfor the \"callback\" functions. The callback was originally useful in order to have\ndifferent parameters for export and non-export ciphersuites. Export ciphersuites are no\nlonger supported by OpenSSL. Use of the callback functions should be replaced by one of\nthe other methods described above.\n\n• SSLCTXsettlsextticketkeycb()\n\nUse the new SSLCTXsettlsextticketkeyevpcb(3) function instead.\n\n• WHIRLPOOL(), WHIRLPOOLInit(), WHIRLPOOLUpdate(), WHIRLPOOLFinal(),\nWHIRLPOOLBitUpdate()\n\nSee \"Deprecated low-level digest functions\". The Whirlpool algorithm has been moved to\nthe Legacy Provider.\n\n• X509certificatetype()\n\nThis was an undocumented function. Applications can use X509get0pubkey(3) and\nX509get0signature(3) instead.\n\n• X509httpnbio(), X509CRLhttpnbio()\n\nUse X509loadhttp(3) and X509CRLloadhttp(3) instead.\n\nNID handling for provided keys and algorithms\n\nThe following functions for NID (numeric id) handling have changed semantics.\n\n• EVPPKEYid(), EVPPKEYgetid()\n\nThis function was previously used to reliably return the NID of an EVPPKEY object, e.g.,\nto look up the name of the algorithm of such EVPPKEY by calling OBJnid2sn(3). With the\nintroduction of provider(7)s EVPPKEYid() or its new equivalent EVPPKEYgetid(3) might\nnow also return the value -1 (EVPPKEYKEYMGMT) indicating the use of a provider to\nimplement the EVPPKEY object. Therefore, the use of EVPPKEYget0typename(3) is\nrecommended for retrieving the name of the EVPPKEY algorithm.\n" }, { "name": "Using the FIPS Module in applications", "content": "See fipsmodule(7) and OSSLPROVIDER-FIPS(7) for details.\n" }, { "name": "OpenSSL command line application changes", "content": "New applications\n\nopenssl kdf uses the new EVPKDF(3) API. openssl kdf uses the new EVPMAC(3) API.\n\nAdded options\n" }, { "name": "-provider_path -provider", "content": "any providers, such as the 'legacy' provider or third party providers. If used then the\n'default' provider would also need to be specified if required. The -providerpath must be\nspecified before the -provider option.\n\nThe list app has many new options. See openssl-list(1) for more information.\n" }, { "name": "-crl_lastupdate -crl_nextupdate", "content": "the generated CRL.\n\nRemoved options\n\nInteractive mode is not longer available.\n\nThe -crypt option used by openssl passwd. The -c option used by openssl x509, openssl\ndhparam, openssl dsaparam, and openssl ecparam.\n\nOther Changes\n\nThe output of Command line applications may have minor changes. These are primarily changes\nin capitalisation and white space. However, in some cases, there are additional differences.\nFor example, the DH parameters output from openssl dhparam now lists 'P', 'Q', 'G' and\n'pcounter' instead of 'prime', 'generator', 'subgroup order' and 'counter' respectively.\n\nThe openssl commands that read keys, certificates, and CRLs now automatically detect the PEM\nor DER format of the input files so it is not necessary to explicitly specify the input\nformat anymore. However if the input format option is used the specified format will be\nrequired.\n\nopenssl speed no longer uses low-level API calls. This implies some of the performance\nnumbers might not be comparable with the previous releases due to higher overhead. This\napplies particularly to measuring performance on smaller data chunks.\n\nb, openssl dsa, openssl gendsa, openssl dsaparam, openssl genrsa and openssl\nrsa have been modified to use PKEY APIs. openssl genrsa and openssl rsa now write PKCS #8\nkeys by default.\n\nDefault settings\n\n\"SHA256\" is now the default digest for TS query used by openssl ts.\n\nDeprecated apps\n\nopenssl rsautl is deprecated, use openssl pkeyutl instead. openssl dhparam, openssl dsa,\nopenssl gendsa, openssl dsaparam, openssl genrsa, openssl rsa, openssl genrsa and openssl rsa\nare now in maintenance mode and no new features will be added to them.\n" }, { "name": "TLS Changes", "content": "• TLS 1.3 FFDHE key exchange support added\n\nThis uses DH safe prime named groups.\n\n• Support for fully \"pluggable\" TLSv1.3 groups.\n\nThis means that providers may supply their own group implementations (using either the\n\"key exchange\" or the \"key encapsulation\" methods) which will automatically be detected\nand used by libssl.\n\n• SSL and SSLCTX options are now 64 bit instead of 32 bit.\n\nThe signatures of the functions to get and set options on SSL and SSLCTX objects changed\nfrom \"unsigned long\" to \"uint64t\" type.\n\nThis may require source code changes. For example it is no longer possible to use the\nSSLOP macro values in preprocessor \"#if\" conditions. However it is still possible to\ntest whether these macros are defined or not.\n\nSee SSLCTXgetoptions(3), SSLCTXsetoptions(3), SSLgetoptions(3) and\nSSLsetoptions(3).\n\n• SSLset1host() and SSLadd1host() Changes\n\nThese functions now take IP literal addresses as well as actual hostnames.\n\n• Added SSL option SSLOPCLEANSEPLAINTEXT\n\nIf the option is set, openssl cleanses (zeroizes) plaintext bytes from internal buffers\nafter delivering them to the application. Note, the application is still responsible for\ncleansing other copies (e.g.: data received by SSLread(3)).\n\n• Client-initiated renegotiation is disabled by default.\n\nTo allow it, use the -clientrenegotiation option, the SSLOPALLOWCLIENTRENEGOTIATION\nflag, or the \"ClientRenegotiation\" config parameter as appropriate.\n\n• Secure renegotiation is now required by default for TLS connections\n\nSupport for RFC 5746 secure renegotiation is now required by default for SSL or TLS\nconnections to succeed. Applications that require the ability to connect to legacy peers\nwill need to explicitly set SSLOPLEGACYSERVERCONNECT. Accordingly,\nSSLOPLEGACYSERVERCONNECT is no longer set as part of SSLOPALL.\n\n• Combining the Configure options no-ec and no-dh no longer disables TLSv1.3\n\nTypically if OpenSSL has no EC or DH algorithms then it cannot support connections with\nTLSv1.3. However OpenSSL now supports \"pluggable\" groups through providers. Therefore\nthird party providers may supply group implementations even where there are no built-in\nones. Attempting to create TLS connections in such a build without also disabling TLSv1.3\nat run time or using third party provider groups may result in handshake failures.\nTLSv1.3 can be disabled at compile time using the \"no-tls13\" Configure option.\n\n• SSLCTXsetciphersuites() and SSLsetciphersuites() changes.\n\nThe methods now ignore unknown ciphers.\n\n• Security callback change.\n\nThe security callback, which can be customised by application code, supports the security\noperation SSLSECOPTMPDH. This is defined to take an EVPPKEY in the \"other\" parameter.\nIn most places this is what is passed. All these places occur server side. However there\nwas one client side call of this security operation and it passed a DH object instead.\nThis is incorrect according to the definition of SSLSECOPTMPDH, and is inconsistent\nwith all of the other locations. Therefore this client side call has been changed to pass\nan EVPPKEY instead.\n\n• New SSL option SSLOPIGNOREUNEXPECTEDEOF\n\nThe SSL option SSLOPIGNOREUNEXPECTEDEOF is introduced. If that option is set, an\nunexpected EOF is ignored, it pretends a close notify was received instead and so the\nreturned error becomes SSLERRORZERORETURN.\n\n• The security strength of SHA1 and MD5 based signatures in TLS has been reduced.\n\nThis results in SSL 3, TLS 1.0, TLS 1.1 and DTLS 1.0 no longer working at the default\nsecurity level of 1 and instead requires security level 0. The security level can be\nchanged either using the cipher string with @SECLEVEL, or calling\nSSLCTXsetsecuritylevel(3). This also means that where the signature algorithms\nextension is missing from a ClientHello then the handshake will fail in TLS 1.2 at\nsecurity level 1. This is because, although this extension is optional, failing to\nprovide one means that OpenSSL will fallback to a default set of signature algorithms.\nThis default set requires the availability of SHA1.\n\n• X509 certificates signed using SHA1 are no longer allowed at security level 1 and above.\n\nIn TLS/SSL the default security level is 1. It can be set either using the cipher string\nwith @SECLEVEL, or calling SSLCTXsetsecuritylevel(3). If the leaf certificate is\nsigned with SHA-1, a call to SSLCTXusecertificate(3) will fail if the security level\nis not lowered first. Outside TLS/SSL, the default security level is -1 (effectively 0).\nIt can be set using X509VERIFYPARAMsetauthlevel(3) or using the -authlevel options\nof the commands.\n" } ] }, "SEE ALSO": { "content": "fipsmodule(7)\n", "subsections": [] }, "HISTORY": { "content": "The migration guide was created for OpenSSL 3.0.\n", "subsections": [] }, "COPYRIGHT": { "content": "Copyright 2021-2023 The OpenSSL Project Authors. All Rights Reserved.\n\nLicensed under the Apache License 2.0 (the \"License\"). You may not use this file except in\ncompliance with the License. You can obtain a copy in the file LICENSE in the source\ndistribution or at .\n\n3.0.13 2026-07-29 MIGRATIONGUIDE(7SSL)", "subsections": [] } }, "summary": "migrationguide - OpenSSL migration guide", "flags": [ { "flag": "", "long": null, "arg": null, "description": "any providers, such as the 'legacy' provider or third party providers. If used then the 'default' provider would also need to be specified if required. The -providerpath must be specified before the -provider option. The list app has many new options. See openssl-list(1) for more information." }, { "flag": "", "long": null, "arg": null, "description": "the generated CRL. Removed options Interactive mode is not longer available. The -crypt option used by openssl passwd. The -c option used by openssl x509, openssl dhparam, openssl dsaparam, and openssl ecparam. Other Changes The output of Command line applications may have minor changes. These are primarily changes in capitalisation and white space. However, in some cases, there are additional differences. For example, the DH parameters output from openssl dhparam now lists 'P', 'Q', 'G' and 'pcounter' instead of 'prime', 'generator', 'subgroup order' and 'counter' respectively. The openssl commands that read keys, certificates, and CRLs now automatically detect the PEM or DER format of the input files so it is not necessary to explicitly specify the input format anymore. However if the input format option is used the specified format will be required. openssl speed no longer uses low-level API calls. This implies some of the performance numbers might not be comparable with the previous releases due to higher overhead. This applies particularly to measuring performance on smaller data chunks. b, openssl dsa, openssl gendsa, openssl dsaparam, openssl genrsa and openssl rsa have been modified to use PKEY APIs. openssl genrsa and openssl rsa now write PKCS #8 keys by default. Default settings \"SHA256\" is now the default digest for TS query used by openssl ts. Deprecated apps openssl rsautl is deprecated, use openssl pkeyutl instead. openssl dhparam, openssl dsa, openssl gendsa, openssl dsaparam, openssl genrsa, openssl rsa, openssl genrsa and openssl rsa are now in maintenance mode and no new features will be added to them." } ], "examples": [], "see_also": [ { "name": "fipsmodule", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/fipsmodule/7/json" } ] }