Confluence Attachments and HTTPS

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.

3 answers

1 accepted

1 vote
Accepted answer

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.

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

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Monday in Confluence

Organizing your space just got easier - Page Tree Drag & Drop is here

Hi Community! I’m Elaine, Confluence Product Manager. You may have read my earlier post about page tree in space navigation sidebar. I'm excited to share another improvement that helps you organize ...

139 views 3 4
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you