Confluence Attachments and HTTPS
Asked by Justin Carter:

I just configured both our JIRA and Confluence to listen on HTTP and HTTPS (they were just listening on HTTP before). But now I am having problems uploading any attachments in Confluence. When I try to upload a file I get the error "The server is not responding. Please check that it is running." But I don't see any errors in the catalina.out file. Everything works fine in JIRA, I can upload attachments in it.

I followed this documentation:

<https://confluence.atlassian.com/adminjiraserver073/running-jira-applications-over-ssl-or-https-861253906.html>  
<https://confluence.atlassian.com/conf59/running-confluence-over-ssl-or-https-792499769.html>

I noticed a difference between configuring JIRA's web.xml file and Confluence's web.xml file.

From JIRA's documentation: "all URLs except attachments are redirected from HTTP to HTTPS."

It looks like Confluence is trying to redirect everything and I'm wondering if this could be related to the issue.

Has anyone gotten Confluence to to listen on both HTTP and HTTPS and not had issues uploading attachements? Thanks for any help.


Answers:
author: Justin Carter
body: I figured out a solution to my issue. I found the following errors in my atlassian-confluence.log file:

2017-03-10 16:44:22,674 ERROR \[http-nio-8444-exec-3\] \[confluence.plugins.dragdrop.UploadAction\] execute Failed to save file.  
-- referer: \<obfuscated url\> \| url: /plugins/drag-and-drop/upload.action \| userName: justin \| action: upload  
java.security.ProviderException: Could not determine buffer size  
at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:843)  
...  
...  
Caused by: javax.crypto.ShortBufferException: Output buffer must be (at least) 12272 bytes long  
at com.oracle.security.ucrypto.NativeGCMCipher.engineUpdate(NativeGCMCipher.java:261)  
at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:828)  
... 379 more

Researching, I found a related link: <http://stackoverflow.com/questions/38254759/tomcat-8-manager-war-deploy-upload-fails-over-ssl>

I tried adding socketBuffer="12272" to my Connector XML entries in my server.xml file but it didn't help. I also tried socketBuffer="-1" but that also didn't help.

The last suggestion about editing the $JAVA_HOME/jre/lib/security/java.security file helped, but required some tweaking. I couldn't just comment out the first provider, like they suggested:

I had to renumber the rest as well.

Original:  
security.provider.1=com.oracle.security.ucrypto.UcryptoProvider $  
{java.home}/lib/security/ucrypto-solaris.cfg  
security.provider.2=sun.security.pkcs11.SunPKCS11 ${java.home}  
/lib/security/sunpkcs11-solaris.cfg  
security.provider.3=sun.security.provider.Sun  
security.provider.4=sun.security.rsa.SunRsaSign  
security.provider.5=[sun.security.ec](http://sun.security.ec).SunEC  
security.provider.6=[com.sun.net](http://com.sun.net).ssl.internal.ssl.Provider  
security.provider.7=com.sun.crypto.provider.SunJCE  
security.provider.8=sun.security.jgss.SunProvider  
security.provider.9=com.sun.security.sasl.Provider  
security.provider.10=org.jcp.xml.dsig.internal.dom.XMLDSigRI  
security.provider.11=sun.security.smartcardio.SunPCSC

New:  
#security.provider.1=com.oracle.security.ucrypto.UcryptoProvider $  
{java.home}/lib/security/ucrypto-solaris.cfg  
security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}  
/lib/security/sunpkcs11-solaris.cfg  
security.provider.2=sun.security.provider.Sun  
security.provider.3=sun.security.rsa.SunRsaSign  
security.provider.4=[sun.security.ec](http://sun.security.ec).SunEC  
security.provider.5=[com.sun.net](http://com.sun.net).ssl.internal.ssl.Provider  
security.provider.6=com.sun.crypto.provider.SunJCE  
security.provider.7=sun.security.jgss.SunProvider  
security.provider.8=com.sun.security.sasl.Provider  
security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI  
security.provider.10=sun.security.smartcardio.SunPCSC

After changing this and restarting Confluence, I can now upload attachments.


author: Justin Carter
body: Thanks, yes we have F5s sitting in front of everything. Up until now, we've had it configured so that the connection between the client and the F5 is encrypted, but the connection between the F5 and the backend servers is unencrypted. I have been working toward encrypting that backend connection. But with all of the work and problems I've run into so far I am starting to regret going down that path. :smile:

I did find out a solution to this particular issue though (see below). It was pretty obscure.


author: Niclas Sandstroem
body: I would revert to standard Tomcat and utilize a proxy like Apache/nginx to handle HTTPS in between the servers or on them.

This way you can terminate the SSL directly there and do some other good stuff. Else if you continue with Tomcat I hope you will figure it out :smile:


Tags: confluence-administration