upgrade to 2.1: missing ssl cert for ssl

[poidl]

Related:
#2923

I upgraded from 2.0 to 2.1 and have the same issue:

Dec 03 15:14:10 mymachine systemd[1]: Started apisix.
Dec 03 15:14:10 mymachine start_apisix.sh[295]: lua: ./bin/apisix:255: missing ssl cert for ssl
Dec 03 15:14:10 mymachine start_apisix.sh[295]: stack traceback:
Dec 03 15:14:10 mymachine start_apisix.sh[295]:         [C]: in function 'error'
Dec 03 15:14:10 mymachine start_apisix.sh[295]:         ./bin/apisix:255: in upvalue 'init'
Dec 03 15:14:10 mymachine start_apisix.sh[295]:         ./bin/apisix:363: in field '?'
Dec 03 15:14:10 mymachine start_apisix.sh[295]:         ./bin/apisix:418: in main chunk
Dec 03 15:14:10 mymachine start_apisix.sh[295]:         [C]: in ?
Dec 03 15:14:11 mymachine systemd[1]: apisix.service: Main process exited, code=exited, status=1/FAILURE
Dec 03 15:14:11 mymachine systemd[1]: apisix.service: Failed with result 'exit-code'.

With 2.0, my config.conf contained

  ssl:
    enable: true

and I could simply follow the "https guide":
https://github.com/apache/apisix/blob/master/doc/https.md
using the certs for my domain from letsencrypt.

This does not work any more with 2.1.

How can I enable ssl for the ssl listen_port for my domain name now? Is it still possible to enable https via the described method without having keys/certs locally in a folder before starting apisix? If not, may I suggest to add the required steps to https://github.com/apache/apisix/blob/master/doc/https.md . I am using a vpn to admin my machines, and run etcd locally on the machines. So there is no need to encrypt that traffic (?).

Also, does the message " lua: ./bin/apisix:255: missing ssl cert for ssl" refer to certs for encrypting to other services like etcd, or does it refer to ssl certs used for serving on port 9443?

Meanwhile I downgraded to 2.0 and it works.

Thanks a lot for your help!

[idbeta]

The 2.1 version disable ssl by default, if you want to enable it, you need to set several configurations in conf.yaml like enable, ssl_cert, ssl_cert_key. After setting, you need to restart APISIX to take effect. cc @nic-chen

[poidl]

But doesn't
https://github.com/apache/apisix/blob/master/doc/https.md
suggest that defining paths in the config file to the cert/key is not necessary? Users are supposed to be able to do this via API calls, or not?
Or do you mean that the path to the cert/key must be defined in the config, but the actual files do not need to be present? And can later be added via the API?

[nic-chen]

@poidl
yes, ssl_cert, ssl_cert_key mainly used to enable https, other certs can be added via the API.

[poidl]

Let me see if I summarize correctly:

If I use apisix for the sole purpose of serving two domains, example1.com and example2.com for which I have two cert/keys from letsencrypt, say

• (fullchain1.pem, privkey1.pem) for example1.com
• (fullchain2.pem, privkey2.pem) for example2.com,

then the suggested steps are:

1. Create a random cert/key (dummycert.pem, dummykey.pem) locally for the purpose of starting apisix. This cert/key is never used for encrypting anything (correct??) [EDIT: I think it's incorrect, see next post]. Since it is not used to encrypt anything, I never have to update or change it (??) [EDIT: I think it's incorrect, see next post].
2. Use the admin API as decribed in https://github.com/apache/apisix/blob/master/doc/https.md to upload the letsencrypt cert/keys with something like

curl http://127.0.0.1:9180/apisix/admin/ssl/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "cert": "$(cat fullchain1.pem)",
    "key":  "$(cat privkey1.pem)",
    "sni": "example1.com"
}'

[poidl]

Oh, I think what I wrote above:

This cert/key is never used for encrypting anything (correct??).

is incorrect, in the default configuration for 2.1. the communication to etcd is encrypted by default, right? In the changelog, it says:

🌅 support TLS connection with etcd.

So that's why you require to have the cert in place at startup right? I was confusing this with the cert for encrypting the communication with the admin port, that's why I didn't understand this.

So in the current default config, but changing:

ssl:
    enable: true
...
port_admin: 9180 
https_admin: false

I still require the local cert/key for etcd.

[nic-chen]

Oh, I think what I wrote above:

This cert/key is never used for encrypting anything (correct??).

is incorrect, in the default configuration for 2.1. the communication to etcd is encrypted by default, right? In the changelog, it says:

🌅 support TLS connection with etcd.

So that's why you require to have the cert in place at startup right? I was confusing this with the cert for encrypting the communication with the admin port, that's why I didn't understand this.

So in the current default config, but changing:

ssl:
    enable: true
...
port_admin: 9180 
https_admin: false

I still require the local cert/key for etcd.

there are two different things here.

what we talk above is about https for client request.

support TLS connection with etcd.

is just TLS not mTLS, so we don't need to config cert/key for it.

[poidl]

So what is the local cert/key used for?

I use letsencrypt certificates for client requests, so I don't need the local cert/key there.
Etcd doesn't need certificates either (if I understand correctly)
I also don't encrypt the traffic through the admin port (apart from my VPN, which is good enough for me).

So what is the local cert/key used for?

Thanks again for you help!

[membphis]

you can use a fake cert/key for your case

[poidl]

Very good, thanks for your help and patience!