Confluence Attachments and HTTPS

[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.

[Justin Carter · Accepted solution]

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.SunEC
security.provider.6=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.SunEC
security.provider.5=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.

[Justin Carter]

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. 

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

[Niclas Sandstroem]

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