related to #14 .

At the current state, due to broken cron, the autoupdate doesn't work at all.

Also, I am not 100% sure but it seems the autoupdate feature does not update certificate at all.

Here's an example of failed update when ran manually:

{"response":{"response":"can't read ssl certificate","result":99,"error":"can't read ssl certificate","debug":[{"result":0,"responses":[{"result":0,"error":"--2017-03-06 14:40:10--  https://raw.githubusercontent.com/jelastic-jps/lets-encrypt/master/scripts/install-le.sh?_r=0.27541487818954036\nResolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.60.133\nConnecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.60.133|:443... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: 741 [text/plain]\nSaving to: \u2018/root/install-le.sh\u2019\n\n     0K                                                       100%  366M=0s\n\n2017-03-06 14:40:11 (366 MB/s) - \u2018/root/install-le.sh\u2019 saved [741/741]\n\n\tpackage libcom_err-devel-1.42.12.wc1-4.el7.centos.x86_64 is already installed\nfatal: destination path '/opt/letsencrypt' already exists and is not an empty directory.\n--2017-03-06 14:40:13--  https://raw.githubusercontent.com/jelastic/jem/master/usr/lib/jelastic/modules/ssl.module\nResolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.60.133\nConnecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.60.133|:443... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: 3054 (3.0K) [text/plain]\nSaving to: \u2018/usr/lib/jelastic/modules/ssl.module\u2019\n\n     0K ..                                                    100% 56.1M=0s\n\n2017-03-06 14:40:13 (56.1 MB/s) - \u2018/usr/lib/jelastic/modules/ssl.module\u2019 saved [3054/3054]","exitStatus":0,"nodeid":137039,"out":""}]},{"result":0,"responses":[{"result":0,"error":"--2017-03-06 14:40:16--  https://raw.githubusercontent.com/jelastic-jps/lets-encrypt/master/scripts/generate-ssl-cert.sh?_r=0.27541487818954036\nResolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.60.133\nConnecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.60.133|:443... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: 2219 (2.2K) [text/plain]\nSaving to: \u2018/root/generate-ssl-cert.sh\u2019\n\n     0K ..                                                    100% 51.4M=0s\n\n2017-03-06 14:40:16 (51.4 MB/s) - \u2018/root/generate-ssl-cert.sh\u2019 saved [2219/2219]","exitStatus":0,"nodeid":137039,"out":""}]},{"result":0,"responses":[{"result":0,"error":"","exitStatus":0,"nodeid":137039,"out":""}]},{"result":0,"responses":[{"result":0,"error":"","exitStatus":0,"nodeid":137039,"out":""}]},{"result":0,"responses":[{"result":0,"error":"From https://github.com/letsencrypt/letsencrypt\n * branch            master     -> FETCH_HEAD\nSaving debug log to /var/log/letsencrypt/letsencrypt.log\nRenewing an existing certificate\nPerforming the following challenges:\ntls-sni-01 challenge for vetportal.royalcanin.co.uk\nWaiting for verification...\nCleaning up challenges\nGenerating key (2048 bits): /etc/letsencrypt/keys/0002_key-certbot.pem\nCreating CSR: /etc/letsencrypt/csr/0002_csr-certbot.pem\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Failed connect to http:80; Connection refused","exitStatus":0,"nodeid":137039,"out":"Already up-to-date.\nIMPORTANT NOTES:\n - Congratulations! Your certificate and chain have been saved at\n   /etc/letsencrypt/live/vetportal.royalcanin.co.uk/fullchain.pem.\n   Your cert will expire on 2017-06-04. To obtain a new or tweaked\n   version of this certificate in the future, simply run\n   letsencrypt-auto again. To non-interactively renew *all* of your\n   certificates, run \"letsencrypt-auto renew\"\n - If you like Certbot, please consider supporting our work by:\n\n   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate\n   Donating to EFF:                    https://eff.org/donate-le\n\nappid = 6576787f36a0251b1acbea9f9860b838\nappdomain = j.layershift.co.uk"}]},{"result":0,"responses":[{"result":0,"error":"","exitStatus":0,"nodeid":137039,"out":"e, simply run\n   letsencrypt-auto again. To non-interactively renew *all* of your\n   certificates, run \"letsencrypt-auto renew\"\n - If you like Certbot, please consider supporting our work by:\n\n   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate\n   Donating to EFF:                    https://eff.org/donate-le\n\nappid = 6576787f36a0251b1acbea9f9860b838\nappdomain = j.layershift.co.uk"}]}]},"result":0,"debug":{"time":37388,"cpu":{"time":98,"usage":"0"}}}

You should add a license and contributor policy to your repo to make it clear that you welcome contributions from 3rd parties, how they will be treated, what processes should be followed etc.

Let's Encrypt already offers Wildacard ssl, but this addon does not support it.

https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579/5

When trying to generate a certificate for either the env.domain of custom domain, it will fail. The detailed error log mentions an error :'user with UID[1] cannot be found'.

What are the exact requirements to be able to install an SSL from let's encrypt? Eg: should a public ip already be assigned, is only apache supported, can I have a loadbalancer in front...

Hi, I'm using Jelastic on your Italian partner Aruba (Jelastic version 5.7). Trying to activating the Let's Encrypt Free SSL on any load-balancer with any associated domain name, I get the following error:

{
  "result":99,
  "method":"evalScript",
  "action":"installScript.script",
  "error":"Error: {\"line\":818,\"name\":\"TypeError\",\"source\":\"script\",\"message\":\"Cannot call method \\\"BindSSL\\\" of undefined\"}",
  "__info":{
    [omitted]
  }
}

That clearly refers to the following line:
https://github.com/jelastic-jps/lets-encrypt/blob/master/scripts/ssl-manager.js#L818

The certificate correctly appears on https://crt.sh/ so it was issued, but the addon broke halfway through.

I've already sent the support request both by the Jelastic App popup and to Aruba direct support, without receiving any reply.

I know it's not up to this Github library to solve the issue, but can you perhaps help me figuring out where the problem could be so I can pinpoint the solution to the provider?

Sometimes the install gets stuck becomes a long running process.
If there is a communication problem with the letsencrypt server, it just gets stuck, with the challange port bound observed on (nginx lb ).

As reported by a user on Stack Overflow, custom SSL - and hence Let's Encrypt - is not supported on the node.js node type, so it should be removed from the Let's Encrypt manifest.

It doesn't allow you to add more domain after the initial setup, I have had to un-install and start again every time I want to add another domain name!

Where in the file system does this store the certificates?

Hello there,
I am trying to get my certificate but getting this error.
system :- debian 9 on digital ocean.
domain name:- ss1.proworktree.com
I am also able to ping the ipaddress from my system and have enabled both ipv4 and ipv6 from digital ocean.
error:-
IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: ss1.proworktree.com
  Type: connection
  Detail: Fetching
  http://ss1.proworktree.com/.well-known/acme-challenge/hIWSTAhj-STzDdsB1rEZXA-Cdafo11xW5Bgf0CsNJxo:
  Timeout

  To fix these errors, please make sure that your domain name was
  entered correctly and the DNS A/AAAA record(s) for that domain
  contain(s) the right IP address. Additionally, please check that
  your computer has a publicly routable IP address and that no
  firewalls are preventing the server from communicating with the
  client. If you're using the webroot plugin, you should also verify
  that you are serving files from the webroot path you provided.

PLATFORM_VERSION=5.0.6
PLATFORM_PROTOCOL_VERSION=1.0
PLATFORM_PROTOCOL_PORT=56985
COMPUTE_TYPE=nginx-ruby
COMPUTE_TYPE_VERSION=1
COMPUTE_TYPE_FULL_VERSION=1.0.0
SENDMAIL_ENABLED=0
FIREWALL_ENABLED=1

After the periodical update of our Let's Encrypt certs, the ownership of /var/www/webroot changed recursively from nginx:nginx to apache:apache. We didn't notice until our app started to throw errors, that it wasn't able to create tempfiles any more. We had to redeploy into another directory and change the nginx configs to point to it.

I've done a quick grep over the project and found this line:

If you remove the add-on and then try to install it again, nothing happens, the installation notification just spins on the dashboard and no operations are performed on container.

Suspect it may be related to #8

STR:

1. Create Env with Apache node
2. Install LE add-on
3. Add balancer node
4. Reconfigure LE addon (add some domain)
5. Remove Balancer node
6. Try to:
   a. Update certificate
   b. Remove add-on from Apache node

ER:

a. Certificate updated w/o errors
b. Addon can be successfully removed

AR:
a.

[15:14:46 Let's.SSL:5]: callScript:  {"action":"callScript","params":{"action":"auto-update"}}
[15:14:47 Let's.SSL:6]: script:  {"body":"var targetAppid = api.dev.apps.CreatePersistence ? \"0b0a98ed30c391ef5855130dfe6d30aa\" : appid;\nvar resp = api.dev.scripting.Eval(targetAppid, session, 'env-1111-7203039-cp-letsencrypt-ssl', {action:'auto-update'});\nif (resp.result == 0 && typeof resp.response === 'object' && resp.response.result != 0) resp = resp.response;\nreturn resp;\n"}
[15:14:48]:> checkPermissions
[15:14:49]:> initCustomConfigs
[15:14:49]:> initCustomConfigs.response: {"result":2391,"responses":[],"source":"JEL","error":"The node group [bl] doesn't exist in environment [env-1111-7203039], appid [0b0a98ed30c391ef5855130dfe6d30aa]"}
[15:14:49]:> sendResp: {"result":2391,"responses":[],"source":"JEL","error":"The node group [bl] doesn't exist in environment [env-1111-7203039], appid [0b0a98ed30c391ef5855130dfe6d30aa]","method":"initCustomConfigs"},true
[15:14:49]:> checkUpdateExpiration
[15:14:50]:> cmd: $( [[ -e /usr/bin/python ]] || ln -s /usr/bin/python3 /usr/bin/python ); jem ssl checkdomain | python -c "import sys, json; print (json.load(sys.stdin)['expiredate'])"
[15:14:50 Let's.SSL:6]: ERROR: script.response: {"result":99,"error":"Error: {\"line\":194,\"name\":\"JavaException\",\"source\":\"env-1111-7203039-cp-letsencrypt-ssl\",\"message\":\"java.text.ParseException: Unparseable date: \\\"{\\\"result\\\":2309,\\\"responses\\\":[],\\\"source\\\":\\\"JEL\\\",\\\"error\\\":\\\"software node with id:[575812] not found for current environment\\\"}\\\"\"}"}
[15:14:50 Let's.SSL]: END EXECUTE REMOTE ACTION: {"result":99,"error":"Error: {\"line\":194,\"name\":\"JavaException\",\"source\":\"env-1111-7203039-cp-letsencrypt-ssl\",\"message\":\"java.text.ParseException: Unparseable date: \\\"{\\\"result\\\":2309,\\\"responses\\\":[],\\\"source\\\":\\\"JEL\\\",\\\"error\\\":\\\"software node with id:[575812] not found for current environment\\\"}\\\"\"}","action":"update.callScript.script"}

b.

[15:03:42 Let's.SSL:4]: callScript:  {"action":"callScript","params":{"action":"uninstall"}}
[15:03:43 Let's.SSL:5]: script:  {"body":"var targetAppid = api.dev.apps.CreatePersistence ? \"0b0a98ed30c391ef5855130dfe6d30aa\" : appid;\nvar resp = api.dev.scripting.Eval(targetAppid, session, 'env-1111-7203039-cp-letsencrypt-ssl', {action:'uninstall'});\nif (resp.result == 0 && typeof resp.response === 'object' && resp.response.result != 0) resp = resp.response;\nreturn resp;\n"}
[15:03:43]:> cmd: crontab -l 2>/dev/null | grep -v '%(scriptPath)' | crontab -,{"scriptPath":"/root/auto-update-ssl-cert.sh","nodeGroup":"bl"}
[15:03:43]:> cmd.response: {"result":2391,"responses":[],"source":"JEL","error":"The node group [bl] doesn't exist in environment [env-1111-7203039], appid [0b0a98ed30c391ef5855130dfe6d30aa]"}
[15:03:43]:> initAddOnExtIp: true
[15:03:44]:> initAddOnExtIp.response: {"result":0}
[15:03:44]:> undeploy
[15:03:44]:> isMoreLEAppInstalled
[15:03:45]:> isMoreLEAppInstalled.response: true
[15:03:45]:> undeploy.response: {"result":0}
[15:03:46]:> cmd: rm -rf %(paths),{"paths":"/opt/letsencrypt /root/generate-ssl-cert.sh /root/letsencrypt_settings /root/install-le.sh /root/validation.sh /root/auto-update-ssl-cert.sh"}
[15:03:46]:> cmd.response: {"result":2309,"responses":[],"source":"JEL","error":"software node with id:[575812] not found for current environment"}
[15:03:46 Let's.SSL:5]: ERROR: script.response: {"result":2309,"method":"cmd","responses":[],"source":"JEL","error":"software node with id:[575812] not found for current environment"}
[15:03:46 Let's.SSL]: process manifest: {"result":2309,"method":"cmd","responses":[],"source":"JEL","error":"software node with id:[575812] not found for current environment","action":"callScript.script"}

The manifest does not work ok with custom domains. Only hoster domains are working ok with Apache.

{"result":0},{"result":4109,"error":"The operation could not be performed","source":"JEL","responses":[{"result":4109,"error":"The operation could not be performed","source":"JEL","errOut":"--2017-08-19 15:38:57-- https://raw.githubusercontent.com/jelastic-jps/lets-encrypt/master/scripts/auto-update-ssl-cert.sh?_r=0.6997932726431145\nResolving raw.githubusercontent.com... 151.101.36.133\nConnecting to raw.githubusercontent.com|151.101.36.133|:443... connected.\nERROR: certificate common name \u201cwww.github.com\u201d doesn\u2019t match requested host name \u201craw.githubusercontent.com\u201d.\nTo connect to raw.githubusercontent.com insecurely, use \u2018--no-check-certificate\u2019.","exitStatus":5,"out":"","nodeid":70642}]},{}]},"result":0}

Can you add punycode support to addon?

This is not working in the current state.
I think you ditched the original version and started from scratch.

The verification process can be performed easier with web-check.
The manifest doesnt cover load balancers
Letsencrypt updates packages like mod_ssl and httpd on the env. That is not ideal.

I modifed your original version and got it working , but I see that you are working on this a different way.

After installing plugin it is not possible to run our application from devices running versions lower than Android 4.4.

Environment:

Jelastic 4.9.5.3 (Elastx)
CentOS 7.2
Nginx 1.10.1

Server solution: Parse Server 2.2.24

Test-devices:

Google Nexus 6 (7.1)
Samsung Galaxy Tab A (6.0.1)
Sony Xperia Z5 Compact (5.1.1)
Motorola Moto X 2013 (4.4.4)
Samsung G313HN (4.4.2)
Galaxy Nexus (4.2.2)

Testing

1. Run tests on ssllabs on our domain and it states support down to 4.0... be available throughTLS 1.0 and these certificates seen in images below
Links:
http://ibb.co/hrWU8v
http://ibb.co/fDkZaa
https://www.ssllabs.com/ssltest/

2. Ran this command in terminal.
openssl s_client -connect domain-name:443

Got this result:

Certificate chain
0 s:/CN=domain-name
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/CN=domain-name
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
2 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Number 2 is available in all devices in Settings -> Security -> Trusted credentials. (Even on Galaxy Nexus, which is not working)

3. Checking Client side for Parse Android SDK fault
This is how Parse does HTTP requests throughout app:
if (hasOkHttpOnClasspath()) { httpClientLibraryName = OKHTTP_NAME; httpClient = new ParseOkHttpClient(socketOperationTimeout, sslSessionCache); } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { httpClientLibraryName = URLCONNECTION_NAME; httpClient = new ParseURLConnectionHttpClient(socketOperationTimeout, sslSessionCache); } else { httpClientLibraryName = APACHE_HTTPCLIENT_NAME; httpClient = new ParseApacheHttpClient(socketOperationTimeout, sslSessionCache); }

Our concerns were the ParseApacheHttpClient, as it states if not OKHttp3 available and less than KitKat (4.4) it should hit that. This library is deprecated since API 20 and we had concerns this would be the issue.

After adding SDK locally and debugging the queries all versions hits hasOkHttp check. Even Galaxy Nexus 4.2.2. So this is not the issue

The Exception that gets thrown on < 4.4 is:
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
According to Android documentation this can happen if:

1. The CA that issued the server certificate was unknown
2. The server certificate wasn't signed by a CA, but was self signed
3. The server configuration is missing an intermediate CA

1 should be the issue as the certificate is not self-signed and the server has an intermediate CA installed (see result in 2)

Links:
https://developer.android.com/training/articles/security-ssl.html#CommonProblems

4. Checking CA Certificates
So after this we started looking at Let's Encrypt certificates Chain of Trust and found out it's crossed-signed using IdenTrust (contrary to what 2, openssl command says pointing it to Digital Signature Trust Co./CN=DST Root CA X3) which should work on all Android versions.

Checking trusted CA Certificates on devices was the next step. We found that IdenTrust was available on these Devices:
Google Nexus 6
Samsung Galaxy Tab A

Not available on these:
Sony Xperia Z5 Compact
Samsung G313HN
Motorola Moto X
Galaxy Nexus (4.2.2)

So this could be ruled out.. Kinda.

Links:
https://letsencrypt.org/certificates/
https://www.identrust.com/support/download_root_cert.html

5. What we've tried

First try at solution:
Adding process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0" to index.js

We found out some have had issue with Parse Cloud Code when enabling HTTPS and found some issues on Parse Server github linking this command as a solution. We had not been experienced this issue with the Cloud code but gave it a try. It did nothing.

Second try at solution: (Temp fix)
Adding Custom CA Certificate to client:

1. Downloaded .pem file (x3) available at Lets Encrypt's certificates site.
2. run command in terminal to extract .crt file from .pem
3. Added file to ROOT on Galaxy Nexus through USB
4. Open Settings on device -> Security - Install from Storage
5. Device prompt Lets Encrypt certificate from ROOT and pressed OK
6. Go in to Trusted Certificates -> Choose User tab -> Lets Encrypt cert is showing.
7. Open application.
8. Log in.
9. Success.

So this is a temporary solution but not a good one. We can send this file to our customers, that gets affected by this, or see if they can update to 4.4. But we need this to be working automatically for all Android versions, as it states it should, running SSLLabs test.

Any thoughts? Is this related to the plugin somehow? As running Lets encrypt by adding it to device works, and it says it uses another CA certificate on the server. We've had some customers hitting this issue, and all devices are below 4.4 KitKat.

The log /var/log/letsencrypt.log does not mention the result of the script execution from the cron task.
Logging should be added to simplify debugging.

Most likely an additional redirect should be added here

Payara was added to the manifest on Jan 11th. Using the Jelastic Dashboard on eApps host, it will install as normal. However, ssl call in Firefox vers. 58 provides the typical "...connection is not secure..." response. If Payara isn't supported, when/will it be and what versions will be supported?

Apart from removing the add-on, script should also take care of file cleanup, so remove whole /etc/letsencrypt

Why do you use why not use Letsencrypt github repo instead of CentOS native certbot package?

Name        : certbot
Arch        : noarch
Version     : 0.9.3
Release     : 1.el7
Size        : 16 k
Repo        : epel/x86_64
Summary     : A free, automated certificate authority client
URL         : https://pypi.python.org/pypi/certbot
License     : ASL 2.0
Description : certbot is a free, automated certificate authority that aims
            : to lower the barriers to entry for encrypting all HTTP traffic on the internet.

Think it would be a better solution and less stuff would be unintentionally installed/upgraded as it is done now.

Obtaining a letsencrypt certificate using http challenge just requires access to any one http port which is very much available in jelastic cloudlets accessible over shared load balancer(slb). Once the certificate is obtained, this certificate can be uploaded to the slb ( https://docs.jelastic.com/custom-ssl-via-slb ), thereby providing letsencrypt ssl for custom domain without the need for external IP. SO, I REQUEST YOU TO IMPLEMENT THIS FEATURE OF LETSENCRYPT SSL WITHOUT EXTERNAL IP ASAP.
Even shared hosting services which cost<$1 per month (and can host python,nodejs and ruby apps ) also offer free letsencrypt ssl for custom domain and here jelastic which advertises that user will pay for only what the user needs requires a public paid IP for letsencrypt ssl . Looking forward to free letsencrypt for custom domain feature soon.

I am trying to update my certificate on Jelastic, and add a new subdomain, (it is already on and working, but it will expire next week), but I get the following error:

An unknown error has occurred. Please try again later. We apologize for the inconvenience.

Does anybody know what could be the problem?
Here are the details:

{"response":"Can't read ssl certificate: key={"result":0,"body":""} cert={"result":0,"body":""} chain={"result":0,"body":""}","message":"Can't read ssl certificate: key={"result":0,"body":""} cert={"result":0,"body":""} chain={"result":0,"body":""}","result":99,"error":"Can't read ssl certificate: key={"result":0,"body":""} cert={"result":0,"body":""} chain={"result":0,"body":""}","debug":[{"result":0,"responses":[{"result":0,"errOut":"--2017-07-11 02:00:02-- https://raw.githubusercontent.com/jelastic-jps/lets-encrypt/master/scripts/install-le.sh?_r=0.8376737327458548\nResolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.56.133\nConnecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.56.133|:443... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: 844 [text/plain]\nSaving to: ‘/root/install-le.sh’\n\n 0K 100% 180M=0s\n\n2017-07-11 02:00:03 (180 MB/s) - ‘/root/install-le.sh’ saved [844/844]\n\n--2017-07-11 02:00:07-- https://raw.githubusercontent.com/jelastic/jem/master/usr/lib/jelastic/modules/ssl.module\nResolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.56.133\nConnecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.56.133|:443... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: 3054 (3.0K) [text/plain]\nSaving to: ‘/usr/lib/jelastic/modules/ssl.module’\n\n 0K .. 100% 33.3M=0s\n\n2017-07-11 02:00:07 (33.3 MB/s) - ‘/usr/lib/jelastic/modules/ssl.module’ saved [3054/3054]","exitStatus":0,"nodeid":105065,"out":""}]},{"result":0,"responses":[{"result":0,"errOut":"--2017-07-11 02:00:08-- https://raw.githubusercontent.com/jelastic-jps/lets-encrypt/master/scripts/generate-ssl-cert.sh?_r=0.8376737327458548\nResolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.56.133\nConnecting to raw.githubusercontent.com

As stated here: https://letsencrypt.org/docs/ipv6-support/, let's encrypt now supports IPv6 and prefers it over IPv4. It would be great if this addon didn't absolutely require an IPv4 address to work.

For example given a balancing node which already has an IPv6 address attached, do not create an IPv4 address, otherwise do it.

related to #10

I'm getting this error now:
Can't read ssl certificate: key={"result":0,"body":""} cert={"result":0,"body":""} chain={"result":0,"body":""}

There is the option (also via jelastic api) to generate a short chain certificate?

This is a minor problem, but still could cause problems.
The whole install process launches a yum update on apache server . This might cause problems in some cases . Updates should be controlled better .
I think this should be avoided , just in case the env has some weird custom settings/modules.

I dont think it is a bug , but something to consider.