Degraded performance Customers may experience issues using Community search. Our team is investigating.
We have a server on which we're running Bitbucket. What I'd like to do is to allow plain http from the intranet (a 10.x.y.z network) and require https (on port 7980) from the outside (we have another system which simply forwards port 7980 to our Bitbucket server). The default http-over-port-7990 Just Works(tm), but I'm not getting SSL working.
What I've done is to create a key in a keystore using the keytool, and then I added a Connector:
<Connector port="7980" protocol="org.apache.coyote.http11.Http11NioProtocol" maxHttpHeaderSize="8192" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" enableLookups="false" disableUploadtimeout="true" useBodyEncodingForURI="true" acceptCount="100" clientAuth="false" sslProtocol="TLS" keyAlias="tomcat" keystoreFile="/etc/bitbucket.jks" keystorePass="xxx" keystoreType="JKS" />
After restarting bitbucket, according to netstat -anl, I can see that it's binding the port. When I try to connect to the server, Firefox keeps trying to get a response. curl says this:
$ curl -vvvvvvvvvvvvvvvv https://xxx:7980 [---] * CAfile: none [---] * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): ^C
It just hangs after the client hello.
What should I be looking closer at? What am I missing?
Problem was me not having read all the details. Instructions note that both the keystore and the key passphrases need to be the same when generating the self-signed key.
I assumed that the keystore passphrase was conceptually the same as the CA's root passphrase, while the key's passphrase is, well, only the key's passphrase – but apparently that is not the case.
I regenerated the self-signed key and made sure to enter the same passphrase in both places and now it works.
Another oddity which may or may not be related; I tried to change the keystoreFile to a file which does not exist and I also tried to change keystorePass to the wrong passphrase. Neither of these seemed to cause any errors to be generated(!). I found a Bitbucket SSL guide which listed some common errors, and I thought I'd trigger them just to see that it's not just ignoring the parameters. I can't find the expected errors in atlassian-bitbucket.log. At first I thought I was editing a server.xml which wasn't in use, but like I mentioned earlier, I can see that if I enable the new Connector in it, the 7980 port becomes bound, and when I remove the Connector the 7980 port no longer becomes bound. I'm definitely editing the right server.xml in some sense.
Just for the heck of it I tried adding a moo="cows" attribute to the Connector and then grep:ed the logs for "moo", but it found no occurrences of it. I don't know how forgiving it's supposed to be, so perhaps that test doesn't actually tell me anything, but it makes me wonder if there's some attribute I've misspelled and it's not catching it.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
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!
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