For players on a very old macOS (like 10.11 old): Accessing Online

$pref::SSL::VerifyPeer = 0;

OS X lacks proper path discovery; it will take the input certs and never // backtrack the graph attempting to discover valid paths. // This can create issues in some situations: // - When OS X changes the trust store, there may be a chain // A -> B -> C -> D // where OS X trusts D (on some versions) and trusts C (on some versions). // If a server supplies a chain A, B, C (cross-signed by D), then this chain // will successfully validate on systems that trust D, but fail for systems // that trust C. If the server supplies a chain of A -> B, then it forces // all clients to fetch C (via AIA) if they trust D, and not all clients // (notably, Firefox and Android) will do this, thus breaking them. // An example of this is the Verizon Business Services root - GTE CyberTrust // and Baltimore CyberTrust roots represent old and new roots that cause // issues depending on which version of OS X being used. // // - A server may be (misconfigured) to send an expired intermediate // certificate. On platforms with path discovery, the graph traversal // will back up to immediately before this intermediate, and then // attempt an AIA fetch or retrieval from local store. However, OS X // does not do this, and thus prevents access. While this is ostensibly // a server misconfiguration issue, the fact that it works on other // platforms is a jarring inconsistency for users. // // - When OS X trusts both C and D (simultaneously), it's possible that the // version of C signed by D is signed using a weak algorithm (e.g. SHA-1), // while the version of C in the trust store's signature doesn't matter. // Since a 'strong' chain exists, it would be desirable to prefer this // chain. // // - A variant of the above example, it may be that the version of B sent by // the server is signed using a weak algorithm, but the version of B // present in the AIA of A is signed using a strong algorithm. Since a // 'strong' chain exists, it would be desirable to prefer this chain. // // - A user keychain may contain a less desirable intermediate or root. // OS X gives the user keychains higher priority than the system keychain, // so it may build a weak chain. // // Because of this, the code below first attempts to validate the peer's // identity using the supplied chain. If it is not trusted (e.g. the OS only // trusts C, but the version of C signed by D was sent, and D is not trusted), // or if it contains a weak chain, it will begin lopping off certificates // from the end of the chain and attempting to verify. If a stronger, trusted // chain is found, it is used, otherwise, the algorithm continues until only // the peer's certificate remains. // // If the loop does not find a trusted chain, the loop will be repeated with // the keychain search order altered to give priority to the System Roots // keychain. // // This does cause a performance hit for these users, but only in cases where // OS X is building weaker chains than desired, or when it would otherwise // fail the connection.

curl https://marbleblast.com

curl marbleblast.com

$pref::SSL::VerifyPeer = 0;