Does CC support SSL connection?

coleman · 04-01-2014, 02:56 PM

I have Calibre running behind SSL encryption. Is CC able to support that? I can't get it to connect successfully that way so far.

Thanks!

chaley · 04-02-2014, 06:19 AM

Quote:

Originally Posted by coleman

I have Calibre running behind SSL encryption. Is CC able to support that? I can't get it to connect successfully that way so far.

Thanks!

It works for me. I have an official certificate and I am running calibre behind apache as a reverse proxy. Apache deals with authentication.

My guess is that a self-signed certificate won't work. We added nothing to CC to allow certificate verification failure exceptions and I don't recall anything in Android settings that would deal with that.

coleman · 04-02-2014, 08:15 AM

Quote:

Originally Posted by chaley

It works for me. I have an official certificate and I am running calibre behind apache as a reverse proxy. Apache deals with authentication.

My guess is that a self-signed certificate won't work. We added nothing to CC to allow certificate verification failure exceptions and I don't recall anything in Android settings that would deal with that.

I have a Comodo cert, with an IIS reverse proxy, so I don't think it's the cert. I'll keep fiddling with it. Do you use the complete URL checkbox, with https, or just leave that unchecked but specify port 443? Or do you specify port 443 and https?

Thanks!

chaley · 04-02-2014, 08:42 AM

I use "complete URL", which for me is required because my library is inside the SSL domain (https://my.domain.org/library). However, I am not convinced that machine/port specification would work even without the /library. CC makes no effort to intuit the protocol from the port. It does, however, intuit the port from the protocol, which is how it knows what to do when it sees https.

I start the calibre content server with the argument "--url-prefix library".

Just in case it might be helpful, here is my apache2 config for SSL connections to the library. I left out all the cruft to set up the certs.

Code:

# Ebook Library CALIBRE https
       <Location "/library">
               AuthType Digest
               AuthName "Library"
               AuthDigestDomain /

               AuthDigestProvider file
               AuthUserFile ......./library_digest_pw.txt
               Require valid-user
       </Location>
       RewriteEngine on
       RewriteRule ^/library/(.*) http://127.0.0.1:9192/library/$1 [proxy]
       RewriteRule ^/library http://127.0.0.1:9192 [proxy]

       SetEnv force-proxy-request-1.0 1
       SetEnv proxy-nokeepalive 1

and for completeness the arguments for calibre server

Code:

DAEMON_ARGS="--with-library $CONTENT --pidfile=$PIDFILE --daemonize -p 9192 --max-opds-ungrouped-items=200 --url-prefix /library"

coleman · 04-03-2014, 01:38 AM

Hmm so I'm not well versed in Java, but it seems like something is not happy about my cert. I don't have any issues using Chrome, Firefox, or the Android browser when going to my site though.

I checked the log and did some googling, which led me to validate I have a complete cert chain, which I do, so I'm not sure what's happening. I think this is the relevant part of the log:

Code:

2014-04-01 13:53:31.000:  ContentServer: creating connection to https://mysite.myurl.com
2014-04-01 13:53:31.186:  Error decrypting. Probably using wrong key.
2014-04-01 13:53:31.187:  Error decrypting. Probably using wrong key.
2014-04-01 13:53:31.187:  Error decrypting. Probably using wrong key.
2014-04-01 13:53:31.188:  Error decrypting. Probably using wrong key.
2014-04-01 13:53:31.189:  Error decrypting. Probably using wrong key.
2014-04-01 13:53:31.189:  Error decrypting. Probably using wrong key.
2014-04-01 13:53:31.190:  Error decrypting. Probably using wrong key.
2014-04-01 13:53:31.191:  ContentServer: checking authentication
2014-04-01 13:53:31.277:  Exception in OnContentServerFound: probably connection failed because CS not running
javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
	at com.android.org.conscrypt.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:146)

I did notice Firefox does actually warn about my site not being completely encryped, but I believe that is because Calibre loads an icon from calibre-ebook.com over http.

Any ideas?

Thanks!

chaley · 04-03-2014, 02:58 AM

The "error decrypting" messages come from inside CC. It stores passwords encrypted using some bits and pieces of the site. It can't successfully encrypt the password until it connects. You can ignore these messages.

The important message is that last one. It is saying that the networking code is unable to verify the certificate. CC uses strict verification, which means that the cert chain must be available and that the host name in the URL must exactly match the host name in the cert.

It sounds as if you have checked using the identical URL from chrome on the device, which is confusing. If it works, then either the cert chain is available or the intermediate certificates are stored in chrome's cert store (which would be unusual). It also might imply that either chrome is not doing hostname verification or that an exception was allowed at some point in the past. Not doing hostname verification creates a *huge* security hole so I would be surprised if it does it, but I don't really know either way.

Do verify that the certificate chain is available in your server. I also use a Comodo (positiveSSL) cert, and to make mine work I had to give apache a "bundle" of certs that form the chain from mine to the root cert. There are three certs in that bundle, none of which are my site cert. They are, in the order they appear:

AddTrustExternalCARoot.crt
PositiveSSLCA2.crt
UTN-USERFirst-Hardware.crt

I don't remember exactly why I had to add the last one (a root cert), but IIRC it didn't work universally until I did.

Have you done something similar with IIS? Looking at the link https://www.onestepssl.com/install_iis5_ssl.php it seems that similar steps are required.

There is another possibility that is hard to check: CC currently is built with Apache's HttpClient 4.2.1, which is out of date. The latest available is 4.3.1. The possibility is that some bugs were fixes in the later releases. I consider this improbable, but not impossible. In any event, during the next prerelease cycle I will update the library. Of course, that doesn't help you now.

chaley · 04-03-2014, 04:34 AM

Quote:

Originally Posted by coleman

I did notice Firefox does actually warn about my site not being completely encryped, but I believe that is because Calibre loads an icon from calibre-ebook.com over http.

Thinking more about this, I realized that I do not get that warning from firefox. That makes me think that perhaps your reverse proxy is not completely filtering links. Alternatively you are using an old version of the calibre content server that did not completely encapsulate content.

To be sure that I hadn't overridden something in the past, I turned on http header capture in firefox (live HTTP headers) and connected to my SSL-hosted library. There were only two http:// requests, both to the verisign certificate revocation authority (evsecure-ocsp.verisign.com). All of the images were served through the reverse proxy using https.

My server is on a VPS in the US running Debian Wheezy. I connected to this server using Firefox. An elided version of the captured headers is under the spoiler.

Spoiler:

coleman · 04-04-2014, 12:31 AM

Quote:

Originally Posted by chaley

Thinking more about this, I realized that I do not get that warning from firefox. That makes me think that perhaps your reverse proxy is not completely filtering links. Alternatively you are using an old version of the calibre content server that did not completely encapsulate content.

Ah, that's interesting.

My proxy should be taking any requests that are coming in on a specifc domain and remapping them. But the one that I think is failing is:

Code:

http://calibre-ebook.com/favicon.ico

But it's in the header, it's not actually visible. But, since it's not coming in on my domain, it wouldn't get re-written. It'd be interesting to see if Calibre still inserts the URL prefix in that link, in which case your re-write rules would still see it, but mine would not.

The other info about the SSL chains, I'll look into. I was pretty sure all the intermediate certs were installed but I'll verify against your process.

Thanks for the help!

04-01-2014, 02:56 PM	#1
coleman Connoisseur Posts: 95 Karma: 38 Join Date: Jul 2007 Device: Android tablets and phones, Windows tablet, Kobo Aura One	Does CC support SSL connection? I have Calibre running behind SSL encryption. Is CC able to support that? I can't get it to connect successfully that way so far. Thanks!

04-02-2014, 08:42 AM	#4
chaley Grand Sorcerer Posts: 12,525 Karma: 8065948 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	I use "complete URL", which for me is required because my library is inside the SSL domain (https://my.domain.org/library). However, I am not convinced that machine/port specification would work even without the /library. CC makes no effort to intuit the protocol from the port. It does, however, intuit the port from the protocol, which is how it knows what to do when it sees https. I start the calibre content server with the argument "--url-prefix library". Just in case it might be helpful, here is my apache2 config for SSL connections to the library. I left out all the cruft to set up the certs. Code: # Ebook Library CALIBRE https <Location "/library"> AuthType Digest AuthName "Library" AuthDigestDomain / AuthDigestProvider file AuthUserFile ......./library_digest_pw.txt Require valid-user </Location> RewriteEngine on RewriteRule ^/library/(.*) http://127.0.0.1:9192/library/$1 [proxy] RewriteRule ^/library http://127.0.0.1:9192 [proxy] SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1 and for completeness the arguments for calibre server Code: DAEMON_ARGS="--with-library $CONTENT --pidfile=$PIDFILE --daemonize -p 9192 --max-opds-ungrouped-items=200 --url-prefix /library"

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Wrapping Calibre in SSL, Issue.	Fmstrat	Calibre	3	01-31-2012 11:29 PM
SSL and content server	timoco	Calibre	2	04-13-2011 11:42 AM
Classic HTTPS/SSL with Classic Nook	cdstech69	Barnes & Noble NOOK	1	02-16-2011 09:40 AM
Wireless internet connection frustrating IDS connection	Socrates	iRex	8	10-21-2009 01:46 PM

04-03-2014, 02:58 AM	#6
chaley Grand Sorcerer Posts: 12,525 Karma: 8065948 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	The "error decrypting" messages come from inside CC. It stores passwords encrypted using some bits and pieces of the site. It can't successfully encrypt the password until it connects. You can ignore these messages. The important message is that last one. It is saying that the networking code is unable to verify the certificate. CC uses strict verification, which means that the cert chain must be available and that the host name in the URL must exactly match the host name in the cert. It sounds as if you have checked using the identical URL from chrome on the device, which is confusing. If it works, then either the cert chain is available or the intermediate certificates are stored in chrome's cert store (which would be unusual). It also might imply that either chrome is not doing hostname verification or that an exception was allowed at some point in the past. Not doing hostname verification creates a huge security hole so I would be surprised if it does it, but I don't really know either way. Do verify that the certificate chain is available in your server. I also use a Comodo (positiveSSL) cert, and to make mine work I had to give apache a "bundle" of certs that form the chain from mine to the root cert. There are three certs in that bundle, none of which are my site cert. They are, in the order they appear: AddTrustExternalCARoot.crt PositiveSSLCA2.crt UTN-USERFirst-Hardware.crt I don't remember exactly why I had to add the last one (a root cert), but IIRC it didn't work universally until I did. Have you done something similar with IIS? Looking at the link https://www.onestepssl.com/install_iis5_ssl.php it seems that similar steps are required. There is another possibility that is hard to check: CC currently is built with Apache's HttpClient 4.2.1, which is out of date. The latest available is 4.3.1. The possibility is that some bugs were fixes in the later releases. I consider this improbable, but not impossible. In any event, during the next prerelease cycle I will update the library. Of course, that doesn't help you now.