sam15
asked on
How to fix SSL certificate vulnerabilities..
Hi
The tenable security scanner is reporting several vulnerabilities related to an IIS web server and tomcat 9 web server.
I recently migrated a windows 2008 server to windows 2016 server and copied the SSL certificate on the old one to the new one. The two machines have different server name.
The domain for the certificate is the same though.
What is the best way to fix these vulnerabilities?
Do I need to generate a new request and issue and install a new certificate from GoDaddy or can those go away by regenerating the existing certificates.
There is one vulnerability related to hostname and one related to provider not being trusted.
======================================================================
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.
Contact the Certificate Authority to have the SSL certificate reissued.
======================================================================
SSL Certificate with Wrong Hostname
The 'commonName' (CN) attribute of the SSL certificate presented for this service is for a different machine.
Purchase or generate a proper SSL certificate for this service.
======================================================================
SSL Certificate Cannot Be Trusted
The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below :
- First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority.
- Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates.
- Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.
If the remote host is a public host in production, any break in the chain makes it more difficult for users to verify the authenticity and identity of the web server. This could make it easier to carry out man-in-the-middle attacks against the remote host.
Purchase or generate a proper SSL certificate for this service.
======================================================================
The tenable security scanner is reporting several vulnerabilities related to an IIS web server and tomcat 9 web server.
I recently migrated a windows 2008 server to windows 2016 server and copied the SSL certificate on the old one to the new one. The two machines have different server name.
The domain for the certificate is the same though.
What is the best way to fix these vulnerabilities?
Do I need to generate a new request and issue and install a new certificate from GoDaddy or can those go away by regenerating the existing certificates.
There is one vulnerability related to hostname and one related to provider not being trusted.
======================================================================
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.
Contact the Certificate Authority to have the SSL certificate reissued.
======================================================================
SSL Certificate with Wrong Hostname
The 'commonName' (CN) attribute of the SSL certificate presented for this service is for a different machine.
Purchase or generate a proper SSL certificate for this service.
======================================================================
SSL Certificate Cannot Be Trusted
The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below :
- First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority.
- Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates.
- Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.
If the remote host is a public host in production, any break in the chain makes it more difficult for users to verify the authenticity and identity of the web server. This could make it easier to carry out man-in-the-middle attacks against the remote host.
Purchase or generate a proper SSL certificate for this service.
======================================================================
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
1) I did not create any self signed certificates. I am wondering if windows 2016 or IIS has self signed certificates by default.
Best to create some sort of cert yourself.
Whether a real cert (like LetsEncrypt) or a Private CA cert.
2) The SSL certificate I copied is issued by godaddy but based on the vulnerabilities listed I am doubting whether it is referring to another self signed certificate on server.
a) Certs never have vulnerabilities. Ever. Period.
b) HTTPS configs can have numerous vulnerabilities.
c) You fix vulnerabilities by adjusting your HTTPS config, not your cert.
d) There is 0 difference in vulnerability potential between self-signed certs + real certs. See #2a + #2b.
3) Is there a way to verify which certificate or domain the scanner is referencing?
Provide your actual domain + port for testing will be required to answer this question.
Many scanners are brain-dead. They generate income by producing false positives or dreck (rubbish, garbage, useless, unactionable) reports meant to prove their value, rather than convey useful information.
4) In order of precedence of usefulness.
a) Use https://www.ssllabs.com/ssltest for testing.
b) Fix your HTTPS config.
c) Fix your HTTPS cert (maybe). At this point I generally use 4096 bit certs, which is likely overkill. Since certs are free, nothing to lose by using 4096 bit certs over 2048.
Also, many testers... the brain-dead ones... will tell you your HTTPS is hackable with 2048 bit certs.
Rather than argue with site owners to justify 2048 bit certs, I use 4096 bit certs.
d) Now run your questionable scanner. If SSLLabs says you're config is good + your random scanner says your config is bad, then dump your scanner, as it's brain-dead.
5) As an example... https://www.ssllabs.com/ssltest/analyze.html?d=davidfavor.com provides the report quality I target for any site I release into the wild.
Best to create some sort of cert yourself.
Whether a real cert (like LetsEncrypt) or a Private CA cert.
2) The SSL certificate I copied is issued by godaddy but based on the vulnerabilities listed I am doubting whether it is referring to another self signed certificate on server.
a) Certs never have vulnerabilities. Ever. Period.
b) HTTPS configs can have numerous vulnerabilities.
c) You fix vulnerabilities by adjusting your HTTPS config, not your cert.
d) There is 0 difference in vulnerability potential between self-signed certs + real certs. See #2a + #2b.
3) Is there a way to verify which certificate or domain the scanner is referencing?
Provide your actual domain + port for testing will be required to answer this question.
Many scanners are brain-dead. They generate income by producing false positives or dreck (rubbish, garbage, useless, unactionable) reports meant to prove their value, rather than convey useful information.
4) In order of precedence of usefulness.
a) Use https://www.ssllabs.com/ssltest for testing.
b) Fix your HTTPS config.
c) Fix your HTTPS cert (maybe). At this point I generally use 4096 bit certs, which is likely overkill. Since certs are free, nothing to lose by using 4096 bit certs over 2048.
Also, many testers... the brain-dead ones... will tell you your HTTPS is hackable with 2048 bit certs.
Rather than argue with site owners to justify 2048 bit certs, I use 4096 bit certs.
d) Now run your questionable scanner. If SSLLabs says you're config is good + your random scanner says your config is bad, then dump your scanner, as it's brain-dead.
5) As an example... https://www.ssllabs.com/ssltest/analyze.html?d=davidfavor.com provides the report quality I target for any site I release into the wild.
ASKER
One problem I have is two sites I have are Private - they are not open for public. SSL Labs could not connect to server. Is there a workaround for this?
I dont understand your statement that certificates dont have any vulnerability. The encryption was reported weak and server name did not match.
Can I fix those issue by tweaking the HTTPS config file as you advise and not reissuing the CERS?
I dont understand your statement that certificates dont have any vulnerability. The encryption was reported weak and server name did not match.
Can I fix those issue by tweaking the HTTPS config file as you advise and not reissuing the CERS?
1) One problem I have is two sites I have are Private - they are not open for public. SSL Labs could not connect to server. Is there a workaround for this?
https://www.experts-exchange.com/questions/29212968/How-to-configure-https-for-web-application-within-an-internal-network.html
describes how I handle this.
When using a Wildcard cert simple solution is to test 1x public host (or domain), then clone the entire HTTPS to all LAN machines.
So... you still can't use SSLLabs to test (all testers can only test public IPs, never LAN/unroutable/private IPs)... so no test + if you use the same HTTPS config as your tested machine, you'll have same security on private machines as public machine(s).
2) I dont understand your statement that certificates dont have any vulnerability. The encryption was reported weak and server name did not match.
There is no such thing as a cert vulnerability only config vulnerability.
Said differently, I can generate a 4096 bit cert to use.
If I have a good config, 0 vulnerabilities.
If I run this cert on a hackable version of Apache or with an incorrect config, I can easily inject any number of vulnerabilities to destroy the cert's integrity/security.
3) Can I fix those issue by tweaking the HTTPS config file as you advise and not reissuing the CERS?
Generally the answer to your question is "yes" + no way to say for sure without testing your actual HTTPS config.
Provide your actual URL for testing to answer this question 100% correctly.
Better to test + know, than guess.
https://www.experts-exchange.com/questions/29212968/How-to-configure-https-for-web-application-within-an-internal-network.html
describes how I handle this.
When using a Wildcard cert simple solution is to test 1x public host (or domain), then clone the entire HTTPS to all LAN machines.
So... you still can't use SSLLabs to test (all testers can only test public IPs, never LAN/unroutable/private IPs)... so no test + if you use the same HTTPS config as your tested machine, you'll have same security on private machines as public machine(s).
2) I dont understand your statement that certificates dont have any vulnerability. The encryption was reported weak and server name did not match.
There is no such thing as a cert vulnerability only config vulnerability.
Said differently, I can generate a 4096 bit cert to use.
If I have a good config, 0 vulnerabilities.
If I run this cert on a hackable version of Apache or with an incorrect config, I can easily inject any number of vulnerabilities to destroy the cert's integrity/security.
3) Can I fix those issue by tweaking the HTTPS config file as you advise and not reissuing the CERS?
Generally the answer to your question is "yes" + no way to say for sure without testing your actual HTTPS config.
Provide your actual URL for testing to answer this question 100% correctly.
Better to test + know, than guess.
ASKER
The site is not public - it is blocked by the company firewall so you cant access it to verify security.
The firewall opens up the site for select IP range that belongs to customer.
I think testing via SSL labs is not possible for private site as this one.
Is there a good tutorial on how to create cers using LetsEncrypt to create SSL certificate for IIS 10 and Apache Tomcat web server running on windows 2016 server?
The firewall opens up the site for select IP range that belongs to customer.
I think testing via SSL labs is not possible for private site as this one.
Is there a good tutorial on how to create cers using LetsEncrypt to create SSL certificate for IIS 10 and Apache Tomcat web server running on windows 2016 server?
1) If site is private, then you'll install some TLS test script, like testssl or something similar.
This allows you to install a test script on the actual machine, then test locally.
2) https://www.experts-exchange.com/questions/29209602/StrongSWAN-on-ubuntu-16.html provides a good overview of the commands required to generate an initial cert, then renew the cert forever.
You'll convert these commands to your local setup IIS or whatever server you're running, based on your server docs.
Apache != IIS
So you'll follow Apache docs for Apache + IIS docs for IIS.
How exactly you do this depends on the exact config policy you're currently using, where you'll follow your existing policy, using the cert files generated by the LetsEncrypt client.
This allows you to install a test script on the actual machine, then test locally.
2) https://www.experts-exchange.com/questions/29209602/StrongSWAN-on-ubuntu-16.html provides a good overview of the commands required to generate an initial cert, then renew the cert forever.
You'll convert these commands to your local setup IIS or whatever server you're running, based on your server docs.
Apache != IIS
So you'll follow Apache docs for Apache + IIS docs for IIS.
How exactly you do this depends on the exact config policy you're currently using, where you'll follow your existing policy, using the cert files generated by the LetsEncrypt client.
ASKER
I found out today that two of the vulnerabilities above apply to port 3383 or WIndows RDP port and for self-signed certificate installed by microsoft.
The only vulnerability that applies to domain name is the common host name.
For the RDP port vulnerability, is this fixed by windows O/S group by doing some patching or other way?
The only vulnerability that applies to domain name is the common host name.
For the RDP port vulnerability, is this fixed by windows O/S group by doing some patching or other way?
ASKER
Is it pretty easy to generate and renew certificates using "LetsEncrypt" in various formats for WIndows and RHEL server?