[openssl-users] openssl-1.1.0 - Linker error on Windows

Andrew Hartley

unread,

May 25, 2016, 7:27:45 AM5/25/16

to

I’ve built the openssl-1.1.0 library with no-shared config option on Windows. I’ve linked the library to my application and fixed the few issues with EVP_MD_CTX deprication. When I build my application I get the following link errors:

1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext@4 referenced in function _capi_free_key

1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertGetCertificateContextProperty@16 referenced in function _capi_get_prov_info

1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertOpenStore@20 referenced in function _capi_open_store

1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFindCertificateInStore@24 referenced in function _capi_find_cert

1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertEnumCertificatesInStore@8 referenced in function _capi_find_cert

1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertCloseStore@8 referenced in function _capi_find_key

1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertDuplicateCertificateContext@4 referenced in function _capi_load_ssl_client_cert

Any advice on how this is to be fixed?

Andrew

______________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Michael Wojcik

unread,

May 25, 2016, 10:00:58 AM5/25/16

to

[Ugh, HTML email, which Outlook is still incapable of processing correctly.]

> From: openssl-users [mailto:openssl-us...@openssl.org] On Behalf Of Andrew Hartley
> Sent: Wednesday, May 25, 2016 05:20

> I’ve built the openssl-1.1.0 library with no-shared config option on Windows. I’ve linked the library to my application > and fixed the few issues with EVP_MD_CTX deprication. When I build my application I get the following link errors:

> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext@4 referenced in function _capi_free_key

You have the CAPI engine linked into libcrypto (rather than configuring it for dynamic loading), so you need to link against the Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either when you create libcrypto or when you link your application.

--
Michael Wojcik
Technology Specialist, Micro Focus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Matt Caswell

unread,

May 25, 2016, 10:05:30 AM5/25/16

to

On 25/05/16 14:59, Michael Wojcik wrote:
> [Ugh, HTML email, which Outlook is still incapable of processing
> correctly.]
>
>> From: openssl-users [mailto:openssl-us...@openssl.org] On
>> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20
>
>> I’ve built the openssl-1.1.0 library with no-shared config option
>> on Windows. I’ve linked the library to my application > and fixed
>> the few issues with EVP_MD_CTX deprication. When I build my
>> application I get the following link errors:
>
>> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external
>> symbol __imp__CertFreeCertificateContext@4 referenced in function
>> _capi_free_key
>
> You have the CAPI engine linked into libcrypto (rather than
> configuring it for dynamic loading)

IIRC it is no longer possible to build for static linking but
dynamically load engines (there be dragons).

>, so you need to link against the
> Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either
> when you create libcrypto or when you link your application.
>

Another possibility, if you are not using the CAPI engine, is to disable
it during the OpenSSL build using the no-capieng Configure option.

Matt

Michael Wojcik

unread,

May 25, 2016, 10:36:47 AM5/25/16

to

> From: openssl-users [mailto:openssl-us...@openssl.org] On Behalf

> Of Matt Caswell
> Sent: Wednesday, May 25, 2016 08:05
> To: openss...@openssl.org
> Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows

>
>
> On 25/05/16 14:59, Michael Wojcik wrote:
> >
> >> From: openssl-users [mailto:openssl-us...@openssl.org] On
> >> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20
> >
> >> I’ve built the openssl-1.1.0 library with no-shared config option
> >> on Windows. I’ve linked the library to my application > and fixed
> >> the few issues with EVP_MD_CTX deprication. When I build my
> >> application I get the following link errors:
> >
> >> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external
> >> symbol __imp__CertFreeCertificateContext@4 referenced in function
> >> _capi_free_key
> >
> > You have the CAPI engine linked into libcrypto (rather than
> > configuring it for dynamic loading)
>
> IIRC it is no longer possible to build for static linking but
> dynamically load engines (there be dragons).

Perhaps not. I have a hybrid engine mechanism where I build OpenSSL as a static library but as sharable code, link it statically into my own shared library (DLL on Windows, shared object on Linux/UNIX), and add an engine at runtime. The engine is implemented in my library, so it's not actually dynamically loaded, but it isn't statically linked into OpenSSL either. That seems to work fine, at least for 1.0.1 and 1.0.2.

(Of course, Configure doesn't actually support building OpenSSL as static libraries of sharable code, so we have to edit the configurations we use with each release. But such is life.)

> >, so you need to link against the
> > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either
> > when you create libcrypto or when you link your application.
>
> Another possibility, if you are not using the CAPI engine, is to disable
> it during the OpenSSL build using the no-capieng Configure option.

Yes. I was assuming Andrew wanted CAPI support and had configured it explicitly, but that isn't a safe assumption. If he doesn't need it, then disabling it in the configure options is the most sensible course.

--
Michael Wojcik
Technology Specialist, Micro Focus

Andrew Hartley

unread,

May 25, 2016, 10:44:48 AM5/25/16

to

I've switched it off via the configure options. All working fine now thank you.

Andrew

______________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Matt Caswell

unread,

May 25, 2016, 10:52:35 AM5/25/16

to

The problem is that OpenSSL maintains global state. If you've built
OpenSSL as a shared library then any applications or dynamically loaded
engines all load the same shared library and all have the same global state.

If your application is linked statically to OpenSSL and then dynamically
loads engines which are also linked to OpenSSL...then you essentially
get *two* copies of the state! 1.0.1 and 1.0.2 have some hacks to deal
with this for some of the obvious areas where this will cause problems
in engines (e.g. error queues). You can just about get away with it if
you're lucky - but they really are hacks and you could come unstuck in
some corner cases. In 1.1.0 it was decided that that was an untenable
position.

Matt

Michael Wojcik

unread,

May 25, 2016, 7:46:24 PM5/25/16

to

> From: openssl-users [mailto:openssl-us...@openssl.org] On Behalf
> Of Matt Caswell

> Sent: Wednesday, May 25, 2016 08:52

>
> On 25/05/16 15:35, Michael Wojcik wrote:
> >> From: openssl-users [mailto:openssl-us...@openssl.org] On
> >> Behalf Of Matt Caswell Sent: Wednesday, May 25, 2016 08:05 To:
> >>

> >> IIRC it is no longer possible to build for static linking but
> >> dynamically load engines (there be dragons).
> >
> > Perhaps not. I have a hybrid engine mechanism where I build OpenSSL
> > as a static library but as sharable code, link it statically into my
> > own shared library (DLL on Windows, shared object on Linux/UNIX), and
> > add an engine at runtime. The engine is implemented in my library, so
> > it's not actually dynamically loaded, but it isn't statically linked
> > into OpenSSL either. That seems to work fine, at least for 1.0.1 and
> > 1.0.2.
>
> The problem is that OpenSSL maintains global state. If you've built
> OpenSSL as a shared library then any applications or dynamically loaded
> engines all load the same shared library and all have the same global state.
>
> If your application is linked statically to OpenSSL and then dynamically
> loads engines which are also linked to OpenSSL...then you essentially
> get *two* copies of the state!

Ah. That's not a problem in my case, since both OpenSSL and my engine code are statically linked into a single shared library. Everyone's using the same single copy of OpenSSL. The engine is added to OpenSSL at runtime (if it's needed) as if it were dynamically loaded, but it was there all along.

And while we statically link OpenSSL into our own library, it's built for sharing and our library is shared. We're just not supplying libcrypto and libssl as discrete modules.

(We're very familiar with the issues around shared-library collisions, thanks to decades of dealing with things like Microsoft's broken C runtime, Oracle's inclusion of OpenLDAP in their client, and so on.)

--
Michael Wojcik
Technology Specialist, Micro Focus