Closed jonathanmassehsj closed 2 years ago
The first limitation of a self-signed certificate is to be self-signed... The purpose of this generated certificate is to have a functional https endpoint, which is certainly not production ready. The documentation recommends to use a reverse proxy (apache, nginx), with a proper certificate (from let's encrypt for instance).
The issue is the software Tenent is scanning all localhost and all installed certificate on the machine.
Self-signed certificate is not a risk since it is on 127.0.0.1 (also the machine is not accessible from the outside of internet.) but the issue is that the SHA-1 is deprecated.
To meet the NIST requirement ALL certificate must be SHA-256 and it give a warning on the scanning tool (Tenet) that the machine have a software with a SHA-1.
Then disable the https port by setting org.obiba.opal.https.port
to -1
. See HTTP server configuration
how do you disable https on agate?
I tried to set -1 but it's not starting anymore.
Sorry my fault, I thought it was an opal issue... Unfortunately there is no such https disabling mechanism for agate.
Amazing,
Can you also add the option to mica please?
Done obiba/mica2#4355
Describe the bug On agate, mica and opal Agate version 2.6.1 self-signed certificate is under SHA-1
The certificate should be upgraded to SHA-256
To Reproduce Steps to reproduce the behavior:
Additional context When IT team are scanning port it give an alert saying that
35291 - SSL Certificate Signed Using Weak Hashing Algorithm Synopsis An SSL certificate in the certificate chain has been signed using a weak hash algorithm. Description The remote service uses an SSL certificate chain that has been signed using a cryptographically weak hashing algorithm (e.g. MD2, MD4, MD5, or SHA1). These signature algorithms are known to be vulnerable to collision attacks. An attacker can exploit this to generate another certificate with the same digital signature, allowing an attacker to masquerade as the affected service. Note that this plugin reports all SSL certificate chains signed with SHA-1 that expire after January 1, 2017 as vulnerable. This is in accordance with Google's gradual sunsetting of the SHA-1 cryptographic hash algorithm. Note that certificates in the chain that are contained in the Nessus CA database (known_CA.inc) have been ignored.