Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

The product does not validate, or incorrectly validates, a certificate.

2177 vulnerabilities reference this CWE, most recent first.

GHSA-JQQR-C2R2-9CVR

Vulnerability from github – Published: 2021-08-25 20:42 – Updated: 2023-06-13 20:37
VLAI
Summary
Improper Certificate Validation in security-framework
Details

If custom root certificates were registered with a ClientBuilder, the hostname of the target server would not be validated against its presented leaf certificate. This issue was fixed by properly configuring the trust evaluation logic to perform that check.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "security-framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-18588"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T21:25:26Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "If custom root certificates were registered with a ClientBuilder, the hostname of the target server would not be validated against its presented leaf certificate. This issue was fixed by properly configuring the trust evaluation logic to perform that check.",
  "id": "GHSA-jqqr-c2r2-9cvr",
  "modified": "2023-06-13T20:37:16Z",
  "published": "2021-08-25T20:42:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18588"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sfackler/rust-security-framework/pull/27"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sfackler/rust-security-framework"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2017-0003.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Certificate Validation in security-framework"
}

GHSA-JQRG-VM9X-G728

Vulnerability from github – Published: 2022-05-14 03:00 – Updated: 2022-05-14 03:00
VLAI
Details

"Shpock Boot Sale & Classifieds" app before 3.17.0 -- aka shpock-boot-sale-classifieds/id557153158 -- for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-14612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-12T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "\"Shpock Boot Sale \u0026 Classifieds\" app before 3.17.0 -- aka shpock-boot-sale-classifieds/id557153158 -- for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.",
  "id": "GHSA-jqrg-vm9x-g728",
  "modified": "2022-05-14T03:00:03Z",
  "published": "2022-05-14T03:00:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14612"
    },
    {
      "type": "WEB",
      "url": "https://www.crissyfield.de/blog/2017/12/14/missing-certificate-validation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JR27-6H3M-PQQQ

Vulnerability from github – Published: 2022-05-13 01:26 – Updated: 2022-05-13 01:26
VLAI
Details

Cisco IOS before 15.0(1)XA1 does not clear the public key cache upon a change to a certificate map, which allows remote authenticated users to bypass a certificate ban by connecting with a banned certificate that had previously been valid, aka Bug ID CSCta79031.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2010-4685"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-01-07T19:00:00Z",
    "severity": "MODERATE"
  },
  "details": "Cisco IOS before 15.0(1)XA1 does not clear the public key cache upon a change to a certificate map, which allows remote authenticated users to bypass a certificate ban by connecting with a banned certificate that had previously been valid, aka Bug ID CSCta79031.",
  "id": "GHSA-jr27-6h3m-pqqq",
  "modified": "2022-05-13T01:26:33Z",
  "published": "2022-05-13T01:26:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4685"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/64586"
    },
    {
      "type": "WEB",
      "url": "http://www.cisco.com/en/US/docs/ios/15_0/15_0x/15_01_XA/rn800xa.pdf"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/45769"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JRP2-P3PX-F5P5

Vulnerability from github – Published: 2026-09-13 00:31 – Updated: 2026-09-13 00:31
VLAI
Details

Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the api_ssl_verify and upstream_ssl_verify configuration keys are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false', and the OpenResty/Lua HTTP client used for outbound requests accepts any certificate, including self-signed and otherwise untrusted certificates, without validating the chain. An attacker positioned to intercept traffic between Socket Firewall and the Socket API or an upstream package registry can present a crafted certificate and modify responses in transit, including substituting malicious package content or altering the allow/block decisions the firewall enforces. Setting api_ssl_verify: true and upstream_ssl_verify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit lua_ssl_trusted_certificate, and thus verification could not be used successfully without manually patching the generated configuration. Version 2.0.0 changes the default for both settings to true.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-90651"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-13T00:17:07Z",
    "severity": "HIGH"
  },
  "details": "Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the api_ssl_verify and upstream_ssl_verify configuration keys are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY=\u0027false\u0027 and UPSTREAM_SSL_VERIFY=\u0027false\u0027, and the OpenResty/Lua HTTP client used for outbound requests accepts any certificate, including self-signed and otherwise untrusted certificates, without validating the chain. An attacker positioned to intercept traffic between Socket Firewall and the Socket API or an upstream package registry can present a crafted certificate and modify responses in transit, including substituting malicious package content or altering the allow/block decisions the firewall enforces. Setting api_ssl_verify: true and upstream_ssl_verify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit lua_ssl_trusted_certificate, and thus verification could not be used successfully without manually patching the generated configuration. Version 2.0.0 changes the default for both settings to true.",
  "id": "GHSA-jrp2-p3px-f5p5",
  "modified": "2026-09-13T00:31:20Z",
  "published": "2026-09-13T00:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90651"
    },
    {
      "type": "WEB",
      "url": "https://docs.socket.dev/docs/registry-mode-configuration-reference"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SocketDev/socket-registry-firewall/releases/tag/v2.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JRW2-3GWX-J89G

Vulnerability from github – Published: 2024-10-22 18:32 – Updated: 2024-10-22 18:32
VLAI
Details

IBM Concert 1.0.0 and 1.0.1 vulnerable to attacks that rely on the use of cookies without the SameSite attribute.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-22T15:15:07Z",
    "severity": "MODERATE"
  },
  "details": "IBM Concert 1.0.0 and 1.0.1 vulnerable to attacks that rely on the use of cookies without the SameSite attribute.",
  "id": "GHSA-jrw2-3gwx-j89g",
  "modified": "2024-10-22T18:32:11Z",
  "published": "2024-10-22T18:32:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43177"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7173596"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JV36-M28H-Q393

Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35
VLAI
Details

Tesla Model X vehicles before 2020-11-23 do not perform certificate validation during an attempt to pair a new key fob with the body control module (BCM). This allows an attacker (who is inside a vehicle, or is otherwise able to send data over the CAN bus) to start and drive the vehicle with a spoofed key fob.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-29440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-30T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Tesla Model X vehicles before 2020-11-23 do not perform certificate validation during an attempt to pair a new key fob with the body control module (BCM). This allows an attacker (who is inside a vehicle, or is otherwise able to send data over the CAN bus) to start and drive the vehicle with a spoofed key fob.",
  "id": "GHSA-jv36-m28h-q393",
  "modified": "2022-05-24T17:35:17Z",
  "published": "2022-05-24T17:35:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29440"
    },
    {
      "type": "WEB",
      "url": "https://www.wired.com/story/tesla-model-x-hack-bluetooth"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JV7Q-HQHW-8W76

Vulnerability from github – Published: 2022-05-17 02:39 – Updated: 2025-04-20 03:39
VLAI
Details

The financial-plus-mobile-banking/id731070564 app 3.0.3 for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-9568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-16T12:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The financial-plus-mobile-banking/id731070564 app 3.0.3 for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.",
  "id": "GHSA-jv7q-hqhw-8w76",
  "modified": "2025-04-20T03:39:12Z",
  "published": "2022-05-17T02:39:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9568"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVF3-MFXV-JCQR

Vulnerability from github – Published: 2022-09-25 00:00 – Updated: 2022-09-30 00:09
VLAI
Summary
Apache Pulsar Broker, Proxy, and WebSocket Proxy vulnerable to Improper Certificate Validation
Details

TLS hostname verification cannot be enabled in the Pulsar Broker's Java Client, the Pulsar Broker's Java Admin Client, the Pulsar WebSocket Proxy's Java Client, and the Pulsar Proxy's Admin Client leaving intra-cluster connections and geo-replication connections vulnerable to man in the middle attacks, which could leak credentials, configuration data, message data, and any other data sent by these clients. The vulnerability is for both the pulsar+ssl protocol and HTTPS. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. This issue affects Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-broker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-broker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-broker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "2.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "2.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-broker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.10.0"
            },
            {
              "fixed": "2.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.10.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar-proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.10.0"
            },
            {
              "fixed": "2.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.10.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2022-33682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-30T00:09:24Z",
    "nvd_published_at": "2022-09-23T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "TLS hostname verification cannot be enabled in the Pulsar Broker\u0027s Java Client, the Pulsar Broker\u0027s Java Admin Client, the Pulsar WebSocket Proxy\u0027s Java Client, and the Pulsar Proxy\u0027s Admin Client leaving intra-cluster connections and geo-replication connections vulnerable to man in the middle attacks, which could leak credentials, configuration data, message data, and any other data sent by these clients. The vulnerability is for both the pulsar+ssl protocol and HTTPS. An attacker can only take advantage of this vulnerability by taking control of a machine \u0027between\u0027 the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. This issue affects Apache Pulsar Broker, Proxy, and WebSocket Proxy versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.",
  "id": "GHSA-jvf3-mfxv-jcqr",
  "modified": "2022-09-30T00:09:24Z",
  "published": "2022-09-25T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33682"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/l0ynfl161qghwfcgbbl8ld9hzbl9t3yx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Pulsar Broker, Proxy, and WebSocket Proxy vulnerable to Improper Certificate Validation"
}

GHSA-JVQ8-2FVP-VCCP

Vulnerability from github – Published: 2022-05-14 01:11 – Updated: 2022-05-14 01:11
VLAI
Details

A certificate validation issue existed in configuration profiles. This was addressed with additional checks. This issue affected versions prior to iOS 12.1.1, tvOS 12.1.1, watchOS 5.1.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-4436"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-03T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "A certificate validation issue existed in configuration profiles. This was addressed with additional checks. This issue affected versions prior to iOS 12.1.1, tvOS 12.1.1, watchOS 5.1.2.",
  "id": "GHSA-jvq8-2fvp-vccp",
  "modified": "2022-05-14T01:11:50Z",
  "published": "2022-05-14T01:11:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-4436"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT209340"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT209342"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT209343"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVWP-XR6V-4M4F

Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11
VLAI
Details

In GNOME grilo though 0.3.13, grl-net-wc.c does not enable TLS certificate verification on the SoupSessionAsync objects it creates, leaving users vulnerable to network MITM attacks. NOTE: this is similar to CVE-2016-20011.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-39365"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-22T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In GNOME grilo though 0.3.13, grl-net-wc.c does not enable TLS certificate verification on the SoupSessionAsync objects it creates, leaving users vulnerable to network MITM attacks. NOTE: this is similar to CVE-2016-20011.",
  "id": "GHSA-jvwp-xr6v-4m4f",
  "modified": "2022-05-24T19:11:59Z",
  "published": "2022-05-24T19:11:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39365"
    },
    {
      "type": "WEB",
      "url": "https://blogs.gnome.org/mcatanzaro/2021/05/25/reminder-soupsessionsync-and-soupsessionasync-default-to-no-tls-certificate-verification"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/grilo/-/issues/146"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/09/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4964"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

Mitigation
Architecture and Design Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

Mitigation
Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.