Update Dockerfiles with certs

[Zhaars]

During playground actualizing, I faced with a problem that KMS Decrypt failed with - request send failed, Post \"https://kms.eu-west-1.amazonaws.com/\": x509: certificate signed by unknown authority".

So the issue is that we didn't copy the ca-certificates.crt to the result container, but ca-certificates is installed in the acra-build Dockerfile, so CA certificates from AWS was signed by an unknown authority.

Checklist

• [ ] Change is covered by automated tests
• [ ] The coding guidelines are followed
• [ ] Public API has proper documentation in the Acra documentation site or has PR on documentation repository with new changes
• [ ] CHANGELOG.md is updated (in case of notable or breaking changes)
• [ ] CHANGELOG_DEV.md is updated
• [ ] Benchmark results are attached (if applicable)
• are up-to-date (in case of API changes)

[Zhaars]

@shadinua Is it good practice, in general, to copy the certificate to the result container in such a way or its better to mount it directly from the host machine where the container is running?

[Zhaars]

as we discussed, who want to fully control all certs, they can mount own certs for containers. for most people, it will be easier for the first try to use containers with pre-uploaded trusted certs.

Agree, but lets wait for @shadinua opinion.

[shadinua]

There are two common acceptable approaches:

1. To mount CA certificates (and, optional, service certificates) from a base host. Usually we want to use this approach in production cases where we manage and trust to the base host.
2. To include service certificates and, optional, CA certificates into the image. There is one significant downside here: the CA certificates cannot be updated, the service certificates cannot be rotated. So this way is extremely inconvenient to use in production. In other hand in such way we get reproducible result at any environment.

In the particular case in bounds of this PR we have production-level images, so I'd tend to refrain from injecting CA certificates into such images. The most significant reason I can see now that such container may stop working unexpectedly and a customer have to upgrade to the new version of the application, which may lead to incompatibility. Sure, there is a way with mounting /etc/ssl directory, but this will require reconfiguration and restart service.

Summing up, it looks risky to me. Sure, there are cases where this approach is very handy. But for this situations I'd suggest to build another image based on the original one, which will statically include CA certificates.

[Lagovas]

okay, agree with @shadinua . So lets skip this PR and mount host directories in our playgrounds where we need general CAs.