HOW-TO disable Microsoft-HTTPAPI /2.0

forgot to include that I have tried RULE_INIT and CLIENT_ACCEPTED already. Both of these produce an error that prevents the irule from being able to be saved.

Error: [command is not valid in current event context

Hi,

RULE_INIT is an event raised only when irule is updated or configuration is loaded (start of services...)

CLIENT_ACCEPTED is raised after TCP handshake. there is no way to answer anything except rejecting connection...

The event HTTP_REQUEST is raised after SSL session established. before HTTP_REQUEST event, the bigIP is not able to reply HTTP redirect as the client did not send any request.

So the answer is... This is not possible yet(Previously, I told it was not possible to reply with certificate based on the URL requested by browser... and SNI appeared, so nothing is impossible, only not implemented yet in TLS 1.2)

To be completely clear, this is not a limitation of BIG-IP or of iRules. Since TLS is used to protect the HTTP transaction, the TLS handshake must be completed before any HTTP data are sent (otherwise, that data stream would not be protected by TLS). An HTTP redirect is the result of an HTTP Response message response code. Thus, the order of events in an HTTPS transaction is always:

1. TCP three-way handshake;
2. TLS handshake;
3. Exchange of HTTP messages.

And to expand just a bit on what @stanislas said, the events you cite correspond to the following action:

• RULE_INIT: fires when a rule is reloaded, typically when the BIG-IP configuration is reloaded or the rule is altered and saved. This event is unrelated to connections, so any connection-related commands (e.g., IP::client_addr or HTTP::redirect) cannot be used in this event;
• CLIENT_ACCEPTED: fires when the underlying TCP three-way handshake completes on the client-side of the connection, but in the case of HTTPS, before the TLS handshake begins. Because this event relates solely to the L4 state machine, commands for higher layer protocols (e.g., HTTP::redirect) cannot be used here;
• HTTP_REQUEST: fires after the HTTP headers are received in full on the client-side. In the case of HTTPS, this occurs after the TLS handshake is completed.

It's not possible 'securely'... If it were available, it would be pretty insecure.

The reason is that redirects are done at the HTTP level. SSL/TLS connections provide the transport for that HTTP layer. So until SSL/TLS has completed, there is no stream for the HTTP protocol to work with.

As for TLS level redirects... Nope... That would leave you open for a MITM attack. The only safe way would be to keep renewing those certs until they're no longer needed...

However you could just get the new company to purchase certs that have both names in them. Then you can just redirect from one name to the other, AFTER the TLS is negotiated with the 'old' name

H