Opened 7 years ago

Last modified 19 months ago

#961 new Bug / Defect

[MacOS] OpenVPN fails to use crypto token when run daemonized

Reported by: z80a Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.4.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:



I’m willing to deploy OpenVPN, authentified with hardware crypto tokens, on MacOS X clients, with Tunnelblick GUI. Unfortunately, it fails, as discussed on!topic/tunnelblick-discuss/f_Rp_2nV-x8.

I investigated a bit, and found out that the problem occurs only when OpenVPN is run daemonized.
I could dig the issue up to a call, by the PKCS#11 library, to the SCardEstablishContext PC/SC function, which returns SCARD_E_NO_SERVICE (“The Smart card resource manager is not running.”) when OpenVPN is run daemonized, and SCARD_S_SUCCESS when it’s not daemonized.

It seems to me that the problem should be related to the way OpenVPN daemonizes itself.

I know little about MacOS (I’m more a Linux guy), but I’d be happy to help investigate this issue.

I have no idea whether this issue is MacOS-specific. I run my tests with MacOS Sierra 10.12.6.

Change History (2)

comment:1 Changed 7 years ago by z80a


I could investigate the issue a little further, and found it should be related to the problem described by Ludovic Rousseau in his blog post:

If that’s right, the problem should not occur with OS X Yosemite or earlier, or with PKCS#11 libraries that do not use PC/SC (like software-only PKCS#11 libraries).

If I understand it correctly, that is an issue that Apple is not willing to fix in his PC/SC implementation… It looks like OpenVPN needs to “exec [it]self” after forking. Unless I’m missing something, it means that OpenVPN would have to exec itself, and then re-parse its arguments and any included configuration file, which looks quite inefficient (not to say stupid).

Last edited 7 years ago by z80a (previous) (diff)

comment:2 Changed 19 months ago by Gert Döring

I think we might have even fixed this en passant by changing the order we do fork() (daemon()) and SSL library initialization.

Can you re-test if this still happens with 2.5 or 2.6_beta2?

Note: See TracTickets for help on using tickets.