small fixes

templates/opt/matrix/config/homeserver.yml.j2

@@ -66,7 +66,9 @@ listeners:
     bind_addresses:
     {{ matrix_https_bind_ips | to_nice_yaml | indent(6) }}
     type: http
+    {% if matrix_tls_enabled %}
     tls: true
+    {% endif %}
     x_forwarded: false
 
     resources:
@@ -146,15 +148,13 @@ listeners:
 # Defaults to 'true'.
 #
 #allow_per_room_profiles: false
-
+{% if matrix_tls_enabled %}
 
 ## TLS ##
-{% if matrix_tls_enabled %}
 tls_certificate_path: "{{ matrix_tls_cert_path }}"
 tls_private_key_path: "{{ matrix_tls_key_path }}"
 tls_dh_params_path: "{{ matrix_tls_dhparam_path }}"
 
-{% endif %}
 # Whether to verify TLS server certificates for outbound federation requests.
 federation_verify_certificates: true
 
@@ -164,46 +164,7 @@ federation_client_minimum_tls_version: 1.2
 # Skip federation certificate verification on the following whitelist
 # of domains.
 federation_certificate_verification_whitelist: []
-
-# List of custom certificate authorities for federation traffic.
-#
-# This setting should only normally be used within a private network of
-# homeservers.
-#
-# Note that this list will replace those that are provided by your
-# operating environment. Certificates must be in PEM format.
-#
-#federation_custom_ca_list:
-#  - myCA1.pem
-#  - myCA2.pem
-#  - myCA3.pem
-
-# List of allowed TLS fingerprints for this server to publish along
-# with the signing keys for this server. Other matrix servers that
-# make HTTPS requests to this server will check that the TLS
-# certificates returned by this server match one of the fingerprints.
-#
-# Synapse automatically adds the fingerprint of its own certificate
-# to the list. So if federation traffic is handled directly by synapse
-# then no modification to the list is required.
-#
-# If synapse is run behind a load balancer that handles the TLS then it
-# will be necessary to add the fingerprints of the certificates used by
-# the loadbalancers to this list if they are different to the one
-# synapse is using.
-#
-# Homeservers are permitted to cache the list of TLS fingerprints
-# returned in the key responses up to the "valid_until_ts" returned in
-# key. It may be necessary to publish the fingerprints of a new
-# certificate and wait until the "valid_until_ts" of the previous key
-# responses have passed before deploying it.
-#
-# You can calculate a fingerprint from a given TLS listener via:
-# openssl s_client -connect $host:$port < /dev/null 2> /dev/null |
-#   openssl x509 -outform DER | openssl sha256 -binary | base64 | tr -d '='
-# or by checking matrix.org/federationtester/api/report?server_name=$host
-#
-#tls_fingerprints: [{"sha256": "<base64_encoded_sha256_fingerprint>"}]
+{% endif %}
 
 ## Database ##
 database: