Core FTP

Hi everyone,
I have an old Win2003 box with CoreFTP server (v1.0 build 283) that I'm migrating to Windows 2012 R2 running the latest version of CoreFTP.

For the migration I've just copied the "config.dat" file from the old server to the new one. Part of the migration includes a domain name change and thus a new certificate.

For the new domain I'm trying to use a Wildcard cert issued from GoDaddy. The process seems simple enough; in the domain setup, you click certs, right click > manage, import your cert and then select your imported cert. Restart the application and everything should be good.

However, when I start CoreFTP I get the following:
[#1] [20150930 15:00:00] Starting domain - ftp.domain.com (#1)...
[#1] [20150930 15:00:00] Loading cert 'certs\00000001'...
[#1] [20150930 15:00:00] Loading cert 'certs\00000001'...
[#1] [20150930 15:00:00] Cert load failed, generating new key...
[#1] [20150930 15:00:00] ftp.domain.com active...

From what I can tell CoreFTP can't import the cert and resorts to creating a self-signed cert.

I've tried the following:
- Running CoreFTP as an administrator and not.
- Using the cert from the old server (which is not a wildcard)
- Issuing a cert from our local CA (also not a wildcard)
- Exporting the cert from the machine's certificate store, renaming it to 00000001 and putting it in the \certs folder
- Creating a new domain domain and importing the cert.
- Disabling the migrated config.dat file and letting CoreFTP create a new one, then creating a new domain with the wildcard certificate.
- I've tried all of these steps on a Windows 7 x64 machine.

Nothing works.

What am I doing wrong? Thanks!

typically it just means it can't open the file. Could be as simple as a file permissions issue.

You can also set the certs directory in global settings (run as admin):
www.coreftp.com/server/help/server_global_settings.htm

I don't think it's a permissions issue. I reinstalled CoreFTP to the root of C:\ and the application creates the "certs" folder and is able to create/modify the 0000001 self-signed cert file without a problem. I've also used procmon to trace the application/filesystem interaction and there's no "Access denied" errors which usually denotes a permissions issue.

It seems more like it can't read the system certificate store in order to import the certificate properly, so it just defaults to creating a self-signed cert.