[openssl-users] How to load local certificate folder on windows

[Jakob Bohm]

On 06/02/2015 20:19, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Dave Thompson
>> Sent: Friday, February 06, 2015 12:04
>>
>> * Windows beginning AIR XP or maybe NT does support links on NTFS,
>> but they're not easy to use and not well known, and I think I saw a recent
>> bug report that they don't even work for OpenSSL,  at least sometimes.
> In modern versions of Windows, NTFS supports three sorts of link-like objects: file symbolic links, directory symbolic links, and junctions, all of which are types of reparse points. Older versions of NTFS only support junctions. These can be created with the mklink command. Prior to Vista, there was no command in the base OS for this purpose, and you needed something like linkd from the Windows Server Resource Kit to manipulate links.
Actually, there is a 4th and 5th form of NTFS native
symbolic links: "POSIX" subsystem symbolic links, which
have all the expected semantics but may not work with
Win32 programs such as OpenSSL; and DFS junctions which
have special semantics for the SMB/CIFS file sharing
protocol.
> I just did a bit of testing with openssl.exe from OpenSSL 1.0.1k. It appears to work correctly with all three.
>
> Windows also supports "shortcuts", but those are a Windows Explorer artifact. They're just files that have a particular extension and particular sort of contents. OpenSSL doesn't support them, but then neither do most programs. Shortcuts were invented for Windows 95 to overcome some of the limitations of the FAT32 filesystem. They're rubbish.
Actually, shortcuts are really desktop/start menu entries,
which store a command line, startup directory, menu icon
and launch options.  They work like the ".desktop" files
in modern Linux desktop environments and should never have
been confused with symbolic links.  They were created as
a more flexible replacement for the Windows 3.x program
manager icon group files.
> And Cygwin provides both hard and symbolic UNIX-style links for NTFS. Hard links can only be to files. I'm not sure how Cygwin implements them, but they seem to work fine with OpenSSL.
All versions of NTFS support hard links natively, though
there is no command in the base OS to create them, and
prior to Windows 2000, they could only be created via
an undocumented API and/or by using the "POSIX" subsystem
(which did include a working ln command though).  When
you run chkdsk (fsck) on an NTFS file system, you will see
inodes referred to as "Files" in the "Master File Table"
and directories as "Indexes".
> Cygwin supports multiple implementations of symbolic links; see https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks. Default symbolic links are ordinary files recognized by the Cygwin library as special, so they aren't handled by (non-Cygwin) OpenSSL. Shortcut-style symlinks are shortcuts, so per above they do not work. Native symlinks are Windows symlinks and should work fine with OpenSSL. The native implementation can be selected by setting the CYGWIN environment variable appropriately, so (contrary to recent messages on the list) there's no reason to rewrite c_rehash for use on Windows.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded