Seafile HTTPS Install on Windows Server 2012 R2; Step-by-Step

A step-by-step tutorial on getting a functional Seafile Windows Server that does HTTP/HTTPS syncing (port 443 only) running on Windows Server 2012 R2 with IIS 8.5 and Seafile Windows Server 4.0.6.

I cannot provide screenshots for every step. I am only documenting what I did, what issues I encountered, and what was my final configuration.  These steps were based off of this post by Jeffrey Tay.

Step 1: Install Seafile Server for Windows. Specifically “Download and Setup Seafile Windows Server“.

Step 2: Install IIS. Courtesy to Jack Stromberg and this post which cover the install in brief. Make sure you can access the IIS default page at http://localhost/ to confirm IIS is running correctly.

Step 3: Install Application Request Routing (ARR) 3.0. Another post by Jack Stromberg covers the install. Download ARR 3.0 and follow steps 1-5 from Jack’s post under “Installing IIS Application Request Routing (ARR) 3”.

Step 4: (Optional) Generate and install your SSL certificate. I hesitate to make this optional, but please go get an SSL certificate. Self-signed certificates were problematic for me with Seafile and the hassle was not worth it.  A kudos to my hosting provider, EZPZ Hosting, who offers free, basic SSL certificates or Godaddy, or NameCheap, or Comodo; all work for a basic SSL certificate.

I’ll refer you to GoDaddy which has a simple write-up for generating the CSR Request and importing the certificate back into IIS. On the right side of the IIS Manager is where you launch the wizard to get the process started.

Step 3: Create your Seafile site. Create an empty directory for the “Physical path:” and select the “SSL certificate” that you created and imported in the prior step.  Note: the screenshot shows “Not selected”. This is where you select your imported certificate.

Step 5: Create a web.config file in the “Physical path:”. Note: other examples on the internet did not properly add the appendQueryString=”true” for both Seafile rules. The web.config first checks if HTTPS is being used, if not it redirects to HTTPS, then it checks to see if it is using the “seafhttp/” subdirectory and reverse proxies to http://127.0.0.1:8082, and lastly it reverse proxies everything else to http://127.0.0.1:8000.

Download the following web.config file (which has clean indenting) or, using Notepad, copy and paste the following into a new web.confg file (Warning: make sure Notepad did not append .txt upon saving):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <location path="" overrideMode="Deny">
 </location>
 <system.webServer>
 <security>
 <requestFiltering allowDoubleEscaping="true" />
 </security>
 <rewrite>
 <rules>
 <clear />
 <rule name="Redirect to HTTPS" enabled="true" stopProcessing="true">
 <match url="(.*)" />
 <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
 <add input="{HTTPS}" pattern="^OFF$" />
 </conditions>
 <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
 </rule>
 <rule name="seafilehttp" stopProcessing="true">
 <match url="seafhttp/(.*)" />
 <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
 <action type="Rewrite" url="http://127.0.0.1:8082/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
 </rule>
 <rule name="seafile" enabled="true" stopProcessing="true">
 <match url="(.*)" />
 <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
 <action type="Rewrite" url="http://localhost:8000/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
 </rule>
 
 </rules>
 <outboundRules>
 <preConditions>
 <preCondition name="ResponseIsHtml1">
 <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
 </preCondition>
 </preConditions>
 </outboundRules>
 </rewrite>
 <httpErrors errorMode="DetailedLocalOnly" />
 </system.webServer>
</configuration>

Step 6: Check “Enable Proxy” under AAR 3.0.  Refer to steps 1-6 courtesy of this article from Microsoft.

Step 7: Enable 2GB large uploads (30MB is the default) in IIS. Open an elevated/ Administrator command prompt and run:

c:\windows\system32\inetsrv\appcmd set config -section:requestFiltering -requestLimits.maxAllowedContentLength:2000000000

See Option 2 from this IPSWITCH knowledge base article.

Step 8: Make sure your Seafile config files are properly set.

In “seahub_settings.py” change and make sure you do not have a trailing “/” after seafhttp.

FILE_SERVER_ROOT = 'https://<your-domain-name>/seafhttp'

In “ccnet.conf” change the following and I have a trailing “/”

SERVICE_URL = https://<your-domain-name>

Step 7: Restart IIS, Seafile, and go test your new, secured, HTTP-sync-enabled Seafile server.

An easy way to test the IIS rewrite rules for seafhttp is trying the following two URLs; adding or removing the trailing “/”. I came across these debugging URLs from a Seafile support forum thread. It identified an error in my web.config that I posted above that was missing the trailing “seafhttp/”.

http://<your-domain-name>/seafhttp

should return “Sorry, but the requested page could not be found.” with the typical Seafile login UI header and footer.

http://<your-domain-name>/seafhttp/protocol-version

should return {“version”: 1} as text-only with no images.

Before trying HTTPS, make sure you can get HTTP working.  Once trying HTTPS, make sure your 2102R2 machine has the correct time.  It must be accurate for HTTPS.  Use NTP.

Here are a few supporting URLs that may be helpful in debugging HTTPS syncing:
Can’t download any file over mobile device
Seafile Protocol: Are ports 8082, 10001 and 12001 safe and/or necessary?
upgraded to new client (4.2.0) bad response 404 for protocol version
Problems using Seahub on non-root domain
Client always tries /seafhttp/protocol-version
Lighttpd rewrite issue (v1.4)

23 thoughts on “Seafile HTTPS Install on Windows Server 2012 R2; Step-by-Step”

  1. Hi, thanks for this guide. I’m having an issue though and would appreciate any feedback. First off, the web.config download has an error on line 28, it should read not . Once that was fixed things are partially working. Note I’m testing on the Seafile server so I’m using localhost in the examples below, but the same happens if I use the FQDN.

    Visiting my base URL redirects properly to Seafile.
    Visiting http://localhost/seafhttp/protocol-version returns a text-only page with the actual protocol version shown.
    Visiting http://localhost/seafhttp/protocol-version/ returns a page cannot be displayed. The same is true if I bypass IIS and directly hit http://localhost:8002/seafhttp/protocol-version/, so I’m somewhat at a loss. It would seem if the server on 8002 can’t display the page, there’s no way IIS will do so. What am I missing?

    Thanks much!
    James

    1. James-
      Good catch; I fixed the “rules” to “rule” on the web.config. It is currently a copy/paste from my current production config.
      I revisited and slightly tweaked the post. It appears that with 4.2.3 and 4.0.6 the debugging URLs respond differently now that HTTPS is default. http://localhost/seafhttp returns “Sorry, but the requested page could not be found.”. http://localhost/seafhttp/protocol-version (no trailing backslash) returns {“version”: 1}.
      I rolled back to 3.1.6 and it followed my original post. I have since updated it.
      I would start from scratch and start simple.

      Check obvious things:

    2. get it working WITHOUT SSL first
    3. get it working WITHOUT SSL first
    4. disable 2012R2 firewall temporarily and then add the port exceptions
    5. disable all IIS rlies and get it running locally
    6. I noticed and fixed a quote mistake on my original post. Your seahub_settings.py sholid be:
      FILE_SERVER_ROOT = ‘https://seafile./seafhttp’
      with no quotes around FILE_SERVER_ROOT and with singles quotes around the URL.
    7. NTP time sync (a MUST if you are using SSL)
    8. Reply back. Here to help.

  2. Thanks for the reply. I didn’t realize the site ate my brackets regarding the web.config change but obviously you figured out the issue. I had also picked up not needing the quotes around FILE_SERVER_ROOT but forgot to mention it.

    I appreciate you checking the debug URLs with the different versions…the behavior you mention in your comment is exactly what I’m seeing. Things work fine locally so I guess it’s time to test off-network. I was just assuming I had a config problem because I wasn’t seeing the same results as you.

    I’ll try this out as soon as I can and post back. Thanks again!

  3. First of all, thank you for your great work. Everything works fine, but using Seafile’s Android app does not allow downloading or uploading of files. Content of directories is shown.
    Any ideas how to solve?

    Thank you and regards,
    Jens

    1. I regularly use the iOS app successfully; uploads and downloads.
      Refer back to Step 7 in the post and the supporting links. From memory, I had a similar issue and it was related to the seafhttp and FILE_SERVER_ROOT.
      If I have the chance, I’ll try to test my current configuration using the Android app.

  4. Thankyou very much for putting this together.

    I have a few questions….

    1. Does the certificate name need to match the site name?

    2. If it does, is the FQDN for seafile server like this seafileusername.mydomain.com or myhostname.mydomain.com or seafileusername.myhostname.mydomain.com?

    3. I have Server Essentials anywhere access setup already and so there is a Default Site setup already with multiple binding to HTTPS 443. Do I need to put the binding in there? I tried creating a new site, but it says there is already multiple sites bound to https with a different certificate do you want to proceed”

      1. Yes. That is the basis for SSL/TLS. As an exmaple, see this support article from DigiCert for details on name mismatches
      2. The FQDN can be whatever points to your Seafile server and matches your certificate (e.g. seafilewhatever.mydomain.com).
      3. IIS is warning you that you already have domain(s) and certificate(s) installed that are bound to certain names. I suspect as part of the default install, IIS generated a self-signed wildcard certificate which is why you are getting the prompt. Self-signed certificates will work but its worth the few dollars to get a basic, real certificate. The “*” binding will apply to all HTTPS sites. If you add a new site that is, going off the example above, “seafilewhatever.mydomain.com” then you will add a matching certificate name and all should work as expected. If you just browser “https://yourserverIP” you will get the self-signed warning for the wildcard “*” that came default with IIS. Cheers.
    1. Do not assign “*”, which is a wildcard, to your Seafile IIS site; define a FQDN. E.g. seafiledomain.mydomain.com.
      You can probably his “Yes” to this dialogue, then specify a FQDN and link the proper certificate that matches the FQDN.
      Last step is to start the newly created IIS site. IIS is only warning you that you cannot have two wildcard HTTPS sites.

  5. Hi,

    I want to thank you for this great manual and it worked perfect for me! 🙂

    But know I have one error. I can’t upload files anymore. Neither via web, nor via Android client.

    ARR is installed and active.
    I used your web.config, just changed port 8000 to 8008, that I use.

    I added this line to my seahub_settings.py:
    FILE_SERVER_ROOT = ‘https://*mydomain*/seafhttp’

    This is, how my ccnet.conf looks.
    [General]
    USER_NAME =
    ID =
    NAME = Zappe’s Cloud
    SERVICE_URL = https://*mydomain*/

    [Network]
    PORT = 10001

    [Client]
    PORT = 13418

    And this is how my seafile.conf looks.
    [database]
    type = sqlite

    [network]
    port = 12001

    [fileserver]
    port = 8082

    [seahub]
    port = 8008
    fastcgi = false

    And all the time, I try to upload a file, I get an ‘Unknown error’.

    Do you have an idea, what’s going wrong?!?

    Thanks a lot and cheers,
    Sebastian

    1. Did uploading ever work? Can you access the web interface and login/upload/download without using HTTPS?
      I wrote this article during the transition to HTTPS syncing. It works for HTTPS syncing but I was able to go back-and-forth.
      I edited you original question to be anonymous.
      Cheers.

      1. Thanks for making anonymous! 😉

        Yes, after installing seafile, uploading worked. I just rolled back the changes (ARR off, deactivated https-site, edited conf files) and now file uploading works again.

        Any tests, I can do, or logs, that help?

        Thanks and cheers!

          1. I know this is a bit old, but I’m struggling to get uploads to work with the IIS rewrite for http/https. Right now my config is exactly what you’ve specified. If I set the SERVICE_URL parameter to http://[IP address]:8000 and browse internally, I can upload with no problem. When trying to use the FQDN for the SERVICE_URL I get “unknown error” when trying to upload.

            If I browse the two URLs you mentioned above, I get “Sorry, but the requested page could not be found.” and “{“version”: 1}” respectively.

          2. Apologies for the delayed reply.
            Is the FQDN local or a public DNS name?
            Does the FQDN resolve to your local IP of the IIS+Seafile server?
            If it resolves to your public IP, is your router properly handling loopback? See here and here for examples with DD-WRT.

  6. Thank you for the awesome guide! I was able to get it working pretty well and so far it’s been treating me better than ownCloud 7.x. I was wondering if the HTTP physical web.config matters or not; are we only concerned with dropping the web.config into HTTPS? Also, is there a way to get both LAN and WAN uploads working at the same time? It seems to be contingent on FILE_SERVER_ROOT and it will only work on one or the other because it’s wanting the address used in the browser otherwise I get an “unknown error.” It will get pretty tiresome to change FSR and restart the service whenever I upload from inside the network. TIA

  7. Ah, nevermind about that, it was my port translation (8443 to 443) on the gateway router. Adding a port proxy within the Windows Seafile host seems to have done the trick.

  8. First, I would like to say that you have created a great guide. I was able to install and get the server running with little difficulty. The issue that I have run into is when I attempted to update my domain password, the server goes down and I get an error 501. At first I thought I would be able to update the password in Windows Credential manager, but no joy. Long story short, I found that C:\inetpub\temp\appPools\seafile. there is a seafil..conf file, and in that file it has a few lines:

    I have tried several things, most recently I removed the application pool; changed my password; and then recreated the application pool. I get the same error. For whatever reason it is using my credentials but did not update them (naturally, I removed my actual information from the line of code).

  9. I followed your guide and was able to get everything set up perfectly. It was working great for a while and then out of the blue the web performance started slowing drastically.

    I tried updating Seafile from 5.1.3 to 6.0.7 which did not help. Frequently, web requests time out with 502.3 bad gateway errors.

Leave a Reply

Your email address will not be published. Required fields are marked *