Error when using TLS server with pgBackRest : [113] No route to host - ssl

I´m trying to implement the TLS server feature available with pgBackRest to use a secure connection between the DB server and the repo server, replacing the previous SSH passwordless setup (that was working fine).
After following the online documentation, I´m having the following error when issuing the stanza-create command :
pgbackrest#pgb-repo$ pgbackrest --stanza=training --log-level-console=info stanza-create
2022-06-13 12:56:55.677 P00 INFO: stanza-create command begin 2.39: --buffer-size=16MB --exec-id=8994-62e5ecac --log-level-console=info --log-level-file=info --pg1-host=pg1-primary --pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt --pg1-host-cert-file=/etc/pgbackrest/cert/pg1-primary.crt --pg1-host-key-file=/etc/pgbackrest/cert/pg1-primary.key --pg1-host-type=tls --pg1-host-user=postgres --pg1-path=/data/postgres/13/pg_data --repo1-path=/backup/pgbackrest --stanza=training
WARN: unable to check pg1: [HostConnectError] unable to connect to 'pg1-primary:8432': [113] No route to host
ERROR: [056]: unable to find primary cluster - cannot proceed
HINT: are all available clusters in recovery?
2022-06-13 12:58:55.835 P00 INFO: stanza-create command end: aborted with exception [056]
The PostgreSQL server is up and running on the the DB host:
[postgres#pg1-primary ~]$ psql -c "SELECT pg_is_in_recovery();"
pg_is_in_recovery
-------------------
f
(1 row)
Question
Why am I having this [113] No route to host error ?
Configuration for each server :
pg1-primary
[postgres#pg1-primary ~]$ cat /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/backup/pgbackrest
repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt
repo1-host-cert-file=/etc/pgbackrest/cert/pgb-repo.crt
repo1-host-key-file=/etc/pgbackrest/cert/pgb-repo.key
repo1-host-type=tls
tls-server-address=*
tls-server-auth=pgb-repo=training
tls-server-ca-file=/etc/pgbackrest/cert/ca.crt
tls-server-cert-file=/etc/pgbackrest/cert/pg1-primary.crt
tls-server-key-file=/etc/pgbackrest/cert/pg1-primary.key
[postgres#pg1-primary ~]$ cat /etc/pgbackrest/conf.d/training.conf
[training]
pg1-path=/data/postgres/13/pg_data
pg1-socket-path=/tmp
repo1-host=pgb-repo
repo1-host-user=pgbackrest
[postgres#pg1-primary ~]$ ll /etc/pgbackrest/cert/
total 20
-rw-------. 1 postgres postgres 1090 Jun 13 12:12 ca.crt
-rw-------. 1 postgres postgres 977 Jun 13 12:12 pg1-primary.crt
-rw-------. 1 postgres postgres 1708 Jun 13 12:12 pg1-primary.key
-rw-------. 1 postgres postgres 977 Jun 13 12:23 pgb-repo.crt
-rw-------. 1 postgres postgres 1704 Jun 13 12:23 pgb-repo.key
pgb-repo
pgbackrest#pgb-repo$ cat /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/backup/pgbackrest
tls-server-address=*
tls-server-auth=pg1-primary=training
tls-server-ca-file=/etc/pgbackrest/cert/ca.crt
tls-server-cert-file=/etc/pgbackrest/cert/pgb-repo.crt
tls-server-key-file=/etc/pgbackrest/cert/pgb-repo.key
pgbackrest#pgb-repo$ cat /etc/pgbackrest/conf.d/training.conf
[training]
pg1-host=pg1-primary
pg1-host-user=postgres
pg1-path=/data/postgres/13/pg_data
pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt
pg1-host-cert-file=/etc/pgbackrest/cert/pg1-primary.crt
pg1-host-key-file=/etc/pgbackrest/cert/pg1-primary.key
pg1-host-type=tls
pgbackrest#pgb-repo$ ll /etc/pgbackrest/cert/
total 20
-rw-------. 1 pgbackrest pgbackrest 1090 Jun 13 12:27 ca.crt
-rw-------. 1 pgbackrest pgbackrest 977 Jun 13 12:27 pg1-primary.crt
-rw-------. 1 pgbackrest pgbackrest 1708 Jun 13 12:27 pg1-primary.key
-rw-------. 1 pgbackrest pgbackrest 977 Jun 13 12:27 pgb-repo.crt
-rw-------. 1 pgbackrest pgbackrest 1704 Jun 13 12:27 pgb-repo.key
The servers are reachable from one another:
[postgres#pg1-primary ~]$ ping pgb-repo
PING pgb-repo.xxxx.com (XXX.XX.XXX.117) 56(84) bytes of data.
64 bytes from pgb-repo.xxxx.com (XXX.XX.XXX.117): icmp_seq=1 ttl=64 time=0.365 ms
64 bytes from pgb-repo.xxxx.com (XXX.XX.XXX.117): icmp_seq=2 ttl=64 time=0.421 ms
pgbackrest#pgb-repo$ ping pg1-primary
PING pg1-primary.xxxx.com (XXX.XX.XXX.116) 56(84) bytes of data.
64 bytes from pg1-primary.xxxx.com (XXX.XX.XXX.116): icmp_seq=1 ttl=64 time=0.325 ms
64 bytes from pg1-primary.xxxx.com (XXX.XX.XXX.116): icmp_seq=2 ttl=64 time=0.298 ms

So actually the issue had to do with the firewall preventing access to the default TLS port (8432) used by pgBackRest.
[root#pgb-server ~]# firewall-cmd --zone=public --add-port=8432/tcp --permanent
[root#pgb-server ~]# firewall-cmd --reload
Once the port was accessible through the firewall I could issue a telnet command successfully (for testing access) - and of course run my pgBackRest commands too.
[pgbackrest#pgb-server]$ telnet pg1-server 8432
Trying 172.XX.XXX.XXX...
Connected to pg1-server.
Escape character is '^]'.

Related

Can't connect to MariaDB via JBDC from Google App Script with SSL

I'm trying to connect to MariaDB with Google App Script.
I've been following this post, and these instructions and used this advice to get the certs setup.
const server = 'x.x.x.x'; //not my actual ip
const port = 3306;
const dbName = 'myDbName';
const username = 'googleusername';
const password = 'hunter2';
const url = 'jdbc:mysql://'+server+':'+port+'/'+dbName+'?useSSL=true';
const serverSslCertificate = '-----BEGIN CERTIFICATE-----\n'+
'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END CERTIFICATE-----';
const clientSslCertificate = '-----BEGIN CERTIFICATE-----\n
'+ 'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END CERTIFICATE-----';
const clientSslKey ='-----BEGIN RSA PRIVATE KEY-----\n
'+ 'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END RSA PRIVATE KEY-----';
var connParams = {
user: username,
password: password,
_serverSslCertificate: serverSslCertificate,
_clientSslCertificate: clientSslCertificate,
_clientSslKey: clientSslKey,
};
When I try to connect, it fails and in MariaDB I can see in the mysql error logs:
2022-10-18 23:01:50 18 [Warning] Access denied for user 'googleusername'#'y.y.y.y' (using password: YES)
And in Apps Script I see
Exception: Failed to establish a database connection. Check connection string, username and password.
If I do:
MariaDB [bitnami_wordpress]> SHOW GLOBAL VARIABLES LIKE '%ssl%' \G
*************************** 1. row ***************************
Variable_name: have_openssl
Value: YES
*************************** 2. row ***************************
Variable_name: have_ssl
Value: DISABLED
*************************** 3. row ***************************
Variable_name: ssl_ca
Value: /opt/bitnami/mariadb/certs/ca.pem
*************************** 4. row ***************************
Variable_name: ssl_capath
Value:
*************************** 5. row ***************************
Variable_name: ssl_cert
Value: /opt/bitnami/mariadb/certs/server-cert.pem
*************************** 6. row ***************************
Variable_name: ssl_cipher
Value:
*************************** 7. row ***************************
Variable_name: ssl_crl
Value:
*************************** 8. row ***************************
Variable_name: ssl_crlpath
Value:
*************************** 9. row ***************************
Variable_name: ssl_key
Value: /opt/bitnami/mariadb/certs/server-key.pem
Found this in the MariaDB startup log:
2022-10-18 23:32:19 0 [Warning] Failed to setup SSL
2022-10-18 23:32:19 0 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed
2022-10-18 23:32:19 0 [Warning] SSL error: error:02001002:system library:fopen:No such file or directory
2022-10-18 23:32:19 0 [Warning] SSL error: error:2006D080:BIO routines:BIO_new_file:no such file
2022-10-18 23:32:19 0 [Warning] SSL error: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
I took a look at the have_ssl = disabled thing, and found this.
bitnami#ip-172-26-11-184:~/stack/mariadb/conf/certs$ ls -lah
total 40K
drwxr-xr-x 2 bitnami root 4.0K Oct 9 04:17 .
drwxrwxr-x 4 root root 4.0K Oct 18 22:10 ..
-rw-r--r-- 1 bitnami root 1.7K Oct 9 04:16 ca-key.pem
-rw-r--r-- 1 bitnami root 1.4K Oct 9 04:17 ca.pem
-rw-r--r-- 1 bitnami root 1.3K Oct 9 04:17 client-cert.pem
-rw------- 1 bitnami root 1.7K Oct 9 04:17 client-key.pem
-rw-r--r-- 1 bitnami root 1.1K Oct 9 04:17 client-req.pem
-rw-r--r-- 1 bitnami root 1.3K Oct 9 04:17 server-cert.pem
-rw------- 1 bitnami root 1.7K Oct 9 04:17 server-key.pem
-rw-r--r-- 1 bitnami root 1.1K Oct 9 04:17 server-req.pem
bitnami#ip-172-26-11-184:~/stack/mariadb/conf$ ls -lah
total 24K
drwxrwxr-x 4 root root 4.0K Oct 18 22:10 .
drwxr-xr-x 12 root root 4.0K Apr 14 2022 ..
drwxrwxr-x 3 root root 4.0K Sep 5 11:52 bitnami
drwxr-xr-x 2 bitnami root 4.0K Oct 9 04:17 certs
-rw-rw-r-- 1 bitnami root 1.1K Oct 18 22:10 my.cnf
-rw-r--r-- 1 root root 1002 Oct 9 04:16 run.sh
Amongst other things in my my.cnf:
[mysqld]
skip_name_resolve
explicit_defaults_for_timestamp
basedir=/opt/bitnami/mariadb
port=3306
tmpdir=/opt/bitnami/mariadb/tmp
socket=/opt/bitnami/mariadb/tmp/mysql.sock
pid_file=/opt/bitnami/mariadb/tmp/mysqld.pid
max_allowed_packet=16M
bind_address=0.0.0.0
log_error=/opt/bitnami/mariadb/logs/mysqld.log
slow_query_log=0
slow_query_log_file=/opt/bitnami/mariadb/logs/mysqld.log
long_query_time=10.0
character_set_server=utf8
collation_server=utf8_general_ci
plugin_dir=/opt/bitnami/mariadb/lib/plugin
ssl_ca=/opt/bitnami/mariadb/certs/ca.pem
ssl_cert=/opt/bitnami/mariadb/certs/server-cert.pem
ssl_key=/opt/bitnami/mariadb/certs/server-key.pem
require_secure_transport=ON
Does anyone have any ideas of what to try next and why it's not working?
I got to the bottom of it.
Lessons learnt:
If
MariaDB [bitnami_wordpress]> SHOW GLOBAL VARIABLES LIKE '%ssl%' \G
shows
Variable_name: have_ssl
Value: DISABLED
Then your server side SSL is not enabled.
Check the MySQL log on reload/restart
[Warning] SSL error: error:02001002:system library:fopen:No such file or directory 2022-10-18 23:32:19 0
This kind of thing is a hint - in my case that I'd listed the paths wrong in the config file
The certificates that are needed on the client side are:
The Certificate Authority (ca.pem)
Client Cert
Client Key
In my case, I had the server cert, rather than the CA certificate.
It may be worth trying to connect with the certificates from a commandline client, but whatever "--ssl-verify-server-cert " does, it isn't what App Script does when it tries to connect.
Thanks #danblack for the pointers and encouragement.

Redis service crashes with "Failed opening the RDB file systemdd (in server root dir /etc/cron.d) for saving: Permission denied"

I am running Redis server version 6.0.6 on Ubuntu 20.04. The process is run by "redis" user.
Sometimes, the Redis process crashes and gets restarted on its own and when this happens, lot of data cached in Redis becomes unavailable. This happens every few days/weeks. I can see the following messages in the logs - saving was working fine till 2:32:43 and suddenly failed at 2:34:15:
133121:C 23 Jun 2021 02:27:54.383 * RDB: 22 MB of memory used by copy-on-write
105798:M 23 Jun 2021 02:27:54.511 * Background saving terminated with success
105798:M 23 Jun 2021 02:29:46.279 * 10000 changes in 60 seconds. Saving...
105798:M 23 Jun 2021 02:29:46.354 * Background saving started by pid 133125
133125:C 23 Jun 2021 02:30:16.363 * DB saved on disk
133125:C 23 Jun 2021 02:30:16.464 * RDB: 18 MB of memory used by copy-on-write
105798:M 23 Jun 2021 02:30:16.583 * Background saving terminated with success
105798:M 23 Jun 2021 02:32:14.138 * 10000 changes in 60 seconds. Saving...
105798:M 23 Jun 2021 02:32:14.222 * Background saving started by pid 133131
133131:C 23 Jun 2021 02:32:42.924 * DB saved on disk
133131:C 23 Jun 2021 02:32:42.988 * RDB: 22 MB of memory used by copy-on-write
105798:M 23 Jun 2021 02:32:43.123 * Background saving terminated with success
105798:M 23 Jun 2021 02:34:14.958 * DB saved on disk
105798:M 23 Jun 2021 02:34:15.705 # Failed opening the RDB file systemdd (in server root dir /etc/cron.d) for saving: Permission denied
=== REDIS BUG REPORT START: Cut & paste starting from here ===
105798:M 23 Jun 2021 02:34:15.705 # Redis 6.0.6 crashed by signal: 11
105798:M 23 Jun 2021 02:34:15.705 # Crashed running the instruction at: 0x55f2e7e35099
105798:M 23 Jun 2021 02:34:15.705 # Accessing address: 0x149968
105798:M 23 Jun 2021 02:34:15.705 # Failed assertion: <no assertion failed> (<no file>:0)
------ STACK TRACE ------
EIP:
/usr/bin/redis-server 172.16.106.88:6379(je_malloc_usable_size+0x89)[0x55f2e7e35099]
Backtrace:
/usr/bin/redis-server 172.16.106.88:6379(logStackTrace+0x4f)[0x55f2e7db2bcf]
/usr/bin/redis-server 172.16.106.88:6379(sigsegvHandler+0xb5)[0x55f2e7db33d5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fb934c173c0]
/usr/bin/redis-server 172.16.106.88:6379(je_malloc_usable_size+0x89)[0x55f2e7e35099]
/usr/bin/redis-server 172.16.106.88:6379(+0x50b79)[0x55f2e7d72b79]
/usr/bin/redis-server 172.16.106.88:6379(rdbSave+0x2ba)[0x55f2e7d9345a]
/usr/bin/redis-server 172.16.106.88:6379(saveCommand+0x67)[0x55f2e7d94ab7]
/usr/bin/redis-server 172.16.106.88:6379(call+0xb1)[0x55f2e7d6a8b1]
/usr/bin/redis-server 172.16.106.88:6379(processCommand+0x4a6)[0x55f2e7d6b446]
/usr/bin/redis-server 172.16.106.88:6379(processCommandAndResetClient+0x14)[0x55f2e7d799e4]
/usr/bin/redis-server 172.16.106.88:6379(processInputBuffer+0x18f)[0x55f2e7d7e39f]
/usr/bin/redis-server 172.16.106.88:6379(+0xe10ac)[0x55f2e7e030ac]
/usr/bin/redis-server 172.16.106.88:6379(aeProcessEvents+0x303)[0x55f2e7d63b83]
/usr/bin/redis-server 172.16.106.88:6379(aeMain+0x1d)[0x55f2e7d63ebd]
/usr/bin/redis-server 172.16.106.88:6379(main+0x4e5)[0x55f2e7d603d5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fb934a370b3]
/usr/bin/redis-server 172.16.106.88:6379(_start+0x2e)[0x55f2e7d606ae]
The service restarts on its own and the Redis server starts working fine for a few days/weeks and crashes again with the same error!
I have checked several posts in SO, but none of them resolve my issue since:
a) The instance where the Redis server is running is in a private network (public access is disabled).
b) The DB file name and dir have not been corrupted as observed from "config get dbfilename" and "config get dir" commands. They show the default values.
c) The permissions of the directories are correct (/var/lib/redis is owned by redis with 755 permissions and /var/lib/redis/dump.rdb is owned by redis with 660 permissions)
Can anyone help me identify the root cause of this issue please?

slapd starts when called directly but won't start from systemctl

running fedora 27 here. I'm attempting to run slapd from a fresh openldap install. When I try and run with systemctl start openldap, the daemon fails to start. journalctl gives the following output:
Jun 19 00:30:25 slapd[1325]: #(#) $OpenLDAP: slapd 2.4.45 (Dec 6 2017 14:25:36) $
mockbuild#buildhw-08.phx2.fedoraproject.org:/builddir/build/BUILD/openldap-2.4.45/openldap-2.4.45/servers/slapd
Jun 19 00:30:25 slapd[1326]: mdb_db_open: database "dc=my-domain,dc=com" cannot be opened: Permission denied (13). Restore from backup!
Jun 19 00:30:25 slapd[1326]: backend_startup_one (type=mdb, suffix="dc=my-domain,dc=com"): bi_db_open failed! (13)
Jun 19 00:30:25 slapd[1326]: slapd stopped.
Jun 19 00:30:25 audit[1326]: AVC avc: denied { map } for pid=1326 comm="slapd" path="/var/lib/ldap/lock.mdb" dev="xvda1" ino=1716389 scontext=system_u:system_r:slapd_t:s0 tcontext=system_u:object_r:slapd_db_t:s0 tclass=file permissive=0
However, if I run the daemon directly with /usr/sbin/slapd -u ldap -d -1 -h "ldap:/// ldaps:/// ldapi:///", the daemon starts with no issue.
My systemctl script is below:
[Unit]
Description=OpenLDAP Server Daemon
After=syslog.target network-online.target
Documentation=man:slapd
Documentation=man:slapd-config
Documentation=man:slapd-hdb
Documentation=man:slapd-mdb
Documentation=file:///usr/share/doc/openldap-servers/guide.html
[Service]
Type=forking
ExecStartPre=/usr/libexec/openldap/check-config.sh
ExecStart=/usr/sbin/slapd -u ldap -h "ldap:/// ldaps:/// ldapi:///"
[Install]
WantedBy=multi-user.target
Alias=openldap.service
I've checked permissions on the ldap config directory and db directory and they seem correct for the ldap user:
[root#localhost operations]# ll /etc/openldap/slapd.d/cn\=config
total 24
drwxr-x---. 2 ldap ldap 4096 Jun 15 23:00 'cn=schema'
-rw-------. 1 ldap ldap 378 Jun 15 23:00 'cn=schema.ldif'
-rw-------. 1 ldap ldap 513 Jun 15 23:00 'olcDatabase={0}config.ldif'
-rw-------. 1 ldap ldap 412 Jun 15 23:00 'olcDatabase={-1}frontend.ldif'
-rw-------. 1 ldap ldap 562 Jun 15 23:00 'olcDatabase={1}monitor.ldif'
-rw-------. 1 ldap ldap 609 Jun 15 23:00 'olcDatabase={2}mdb.ldif'
[root#localhost operations]# ll /var/lib/| grep ldap
drwx------. 2 ldap ldap 4096 Jun 19 00:30 ldap
[root#localhost operations]# ll /var/lib/ldap/
total 0
-rw-------. 1 ldap ldap 8192 Jun 19 00:30 lock.mdb
Any advice would be much appreciated.
It seems you're using back-mdb. Good.
Does your DB directory /var/lib/ldap/ really contain only file lock.mdb?
There should also be a bigger file called data.mdb with the actual data.

Unknown connection on my SSH

I'd like to understand something on my SSH server.
When I type
netstat -an | grep -i ':22'
It came out this :
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 192.168.0.1:22 192.168.0.3:49236 ESTABLISHED
tcp 0 0 192.168.0.1:22 43.229.53.72:16866 ESTABLISHED
My local IP is actually 192.168.0.3 and my server is at 192.168.0.1
How can I interpret 43.229.53.72:16866 ? It appears to be a Chinese address.
who -a
Gives me
2015-09-09 02:05 62 id=si term=0 sortie=0
démarrage système 2015-09-09 02:05
niveau d'exécution 2 2015-09-09 02:05 dernier=S
2015-09-09 02:06 1890 id=l2 term=0 sortie=0
IDENTIFIANT tty1 2015-09-09 02:06 2987 id=1
IDENTIFIANT tty5 2015-09-09 02:06 2991 id=5
IDENTIFIANT tty2 2015-09-09 02:06 2988 id=2
IDENTIFIANT tty4 2015-09-09 02:06 2990 id=4
IDENTIFIANT tty3 2015-09-09 02:06 2989 id=3
IDENTIFIANT ttyAMA0 2015-09-09 02:06 2993 id=T0
IDENTIFIANT tty6 2015-09-09 02:06 2992 id=6
pi + pts/0 2015-09-12 19:17 . 4965 (192.168.0.3)
pts/1 2015-09-12 18:59 3529 id=ts/1 term=0 sortie=0
cat /var/log/auth.log | grep '43.229.53.72'
It appears that 43.229.53.72 tried so much times to connect to my ssh
Sep 8 21:55:21 raspberrypi sshd[30282]: Failed password for root from 43.229.53.72 port 39483 ssh2
Sep 8 21:55:23 raspberrypi sshd[30282]: Failed password for root from 43.229.53.72 port 39483 ssh2
Sep 8 21:55:25 raspberrypi sshd[30282]: Failed password for root from 43.229.53.72 port 39483 ssh2
Sep 8 21:55:25 raspberrypi sshd[30282]: Received disconnect from 43.229.53.72: 11: [preauth]
Sep 8 21:55:25 raspberrypi sshd[30282]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.72 user=root
For sure he tries to brute-force the access and he succeed.
How to kick&blacklist this address and how to prevent from this in the future ?
First note, that establishing TCP connection doesn't mean that the authentication succeed.
On public IP, this is really frequent that bots are trying to connect and try some common passwords and known users. You don't have to worry about this, but you can mitigate this phenomenon by these things:
Install and set up fail2ban as proposed in the other answer
Disable password authentication -- bots don't try public keys or other methods
Disable root login -- most of the bots are trying to connection only to root user
Move your service to different port than 22 -- this is hiding but also mitigates the most of the connections
Install "port-knocking" tool that will hide your service for unauthorized access -- for example fwknop

Starting Typesafe Play Framework using HTTPS/SSL

I'm having trouble getting our system up and running using HTTPS.
I have created a keyfile from our wildcard certificate and placed the keyfile in our ./conf directory:
473 zbeckman:glimpulse-server$ ll conf
total 72
drwxr-xr-x 9 zbeckman staff 306 Sep 7 09:26 ./
drwxr-xr-x 22 zbeckman staff 748 Sep 7 09:32 ../
-rwxr-xr-x 1 zbeckman staff 1213 Sep 7 09:26 application.conf*
-rw-r--r-- 1 zbeckman staff 1374 Sep 7 08:49 glimpulse.keystore
-rw-r--r-- 1 zbeckman staff 1439 Aug 9 15:58 logback.xml
-rwxr-xr-x 1 zbeckman staff 5206 Aug 8 15:36 routes*
-rw-r--r-- 1 zbeckman staff 575 Apr 29 18:55 ws.conf
474 zbeckman:glimpulse-server$
And I have added the following to our ./conf/application.conf file, as per instructions in the Play Configuring HTTPS page:
play.server.https.keyStore.path = "./conf/glimpulse.keystore"
play.server.https.keyStore.password = "xxxxxxxxxxxxx"
And finally, I'm using -Dhttp.port=disabled -Dhttps.port=9000 to try and start the server, but it refuses to start.
Here are the results. Note the last line of output:
472 zbeckman:glimpulse-server$ ./activator start -Dhttp.port=disabled -Dhttps.port=9000
[info] Loading project definition from /Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/project
[info] Set current project to Glimpulse (in build file:/Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/)
[warn] The start command is deprecated, and will be removed in a future version of Play.
[warn] To run Play in production mode, run 'stage' instead, and then execute the generated start script in target/universal/stage/bin.
[warn] To test your application using production mode, run 'testProd' instead.
[info] Wrote /Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/target/scala-2.11/glimpulse_2.11-1.0-SNAPSHOT.pom
(Starting server. Type Ctrl+D to exit logs, the server will remain in background)
Must provide either an HTTP or HTTPS port
473 zbeckman:glimpulse-server$
As far as the keystore goes, I used the Java keytool to generate the store, based on our wildcard domain certificate:
keytool -import -alias tomcat -keystore glimpulse.keystore -trustcacerts -file star_glimpulse_com.crt
That seemed to go just fine, and the keystore was generated without any errors or warnings.
You could try to run it like this:
./activator "start -Dhttp.port=disabled -Dhttps.port=9000"
The quotes may be required to make sure the parameters get passed to the start command the right way.
Simply add this to your application.conf:
https {
# The HTTPS port of the server.
port = 9001
}
and your app will listen on port 9001