Solved: Apigee accepts invalid server certificate (wrong.h... - Page 2

guyhagemans · 06-13-2024 06:35 AM

Hi all,

For a client I needed to validate whether Apigee accepts or rejects server certs that are not properly configured.

To test this I setup a target server to (URL Removed by Staff)

Whatever configuration I use in Apigee, it always accepts this host as valid and simply returns the response. Am I missing some configuration so that Apigee validated the server cert and returns an ssl error when it's invalid?

thank you and kind regards,
Guy

My config on the target endpoint:

    <HTTPTargetConnection>
        <LoadBalancer>
            <MaxFailures>0</MaxFailures>
            <RetryEnabled>true</RetryEnabled>
            <Server name="badssl-test">
                <IsEnabled>true</IsEnabled>
                <IsFallback>false</IsFallback>
                <Weight>1</Weight>
            </Server>
            <TargetDisableSecs>300</TargetDisableSecs>
        </LoadBalancer>
        <SSLInfo>
            <Ciphers/>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <Enabled>true</Enabled>
            <IgnoreValidationErrors>false</IgnoreValidationErrors>
            <Protocols/>
        </SSLInfo>
        <Properties/>
    </HTTPTargetConnection>

The target server points to 'wrong.host.badssl.com'. I tried with SSL enabled (and disabled). When enabled I also loaded the root cert of this address as a truststore, but it makes no difference.

dchiesa1

I'm glad to hear you got to a reasonably good place with this.

@guyhagemans wrote:

and we connect to a backend with SAN names and we don't configure a truststore, what would happen? Does Edge check the SAN names and properly enfore SSL?

Dangit it sure should properly enforce, and if it doesn't, please raise a bug. Edge is documented as supporting SNI and SAN during the handshake and it should do the right thing.

Here's the thing though, I just don't like it when people don't configure a TrustStore. That feels like poor hygiene to me. When I was on the product team I advocated that we stop supporting that scenario - in other words, refuse to deploy proxies that use an https TargetEndpoint that doesn't have a Truststore configured. But I was overruled on that. Effectively Edge backs off to a "default truststore" , the contents of which, afaik, are not clearly documented. If I were an API product manager using Apigee, or a security architect overseeing usage of Apigee, there's no way I would be ok with "oh, just use whatever truststore , it doesn't matter." The apigeelint tool will flag this as an error. But ... that's an external tool, not part of the Apigee product. Anyway I'd advise against "not specifying a Truststore." or said in a less tortuous manner, I advise everyone to explicitly specify a TrustStore, and explicitly manage the certs in that TrustStore. Principle of least Privilege and all that.

Of course what you are asking about is slightly different - you're saying when there's no explicit trustsstore, does Edge perform the TLS enforcement correctly? that means, check the trustchain, check ciphers, check key strength, check validity dates, check CN or SAN agreement, etc.

View solution in original post

Apigee accepts invalid server certificate (wrong.host.badssl.com/)