Validating the Request-URI Based on Certificate Information

When you configure the Oracle® Enterprise Session Border Controller to cache TLS certificate information to validate Request-URIs, it stores the Certificate Subject Name and Certificate Subject Alternative Name (only DNS) it learns from peer certificate attributes. It then takes these actions:

• Extracts the host from the Request-URI of the outgoing INVITE
• Compares this host (exact or wildcard match) with the Certificate Common Name or Certificate Subject Alternative name of the certificate it has received
• Sends out an INVITE if the Certificate Common Name or Certificate Subject Alternative name match; Sends a 403 Forbidden rejection to the endpoint from it received the INVITE if there is no match

Wildcard matching applies only to the prefix of the Request-URI:

*.acme.com
	*.*.acmepacket.com

This diagram shows a peering scenario where the Oracle® Enterprise Session Border Controller receives an INVITE from the calling party, which it processes and prepares to send out INVITE 2. After establishing a TLS connection with the called party and caching the required information, the Oracle® Enterprise Session Border Controller validates the Request-URI. Once validation occurs, the Oracle® Enterprise Session Border Controller sends INVITE 2.

The peer certificate from the called party during the TLS handshake with the Oracle® Enterprise Session Border Controller would look like this. Relevant information in the sample appears in bold font.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9 (0x9)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=MA, L=Woburn, O=Smith Securities, OU=Certificate Authority Dept, CN=Smith Certificate Authority/emailAddress=[e-mail]
        Validity
            Not Before: Dec 10 21:14:56 2009 GMT
            Not After : Jul 11 21:14:56 2019 GMT
        Subject: C=US, ST=MA, L=Woburn, O=Acme Packet, OU=Certificate Authority Dept, CN=*.acme.com/emailAddress=[e-mail]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
        X509v3 extensions:
            X509v3 Basic Constraints:
            CA:FALSE
            X509v3 Issuer Alternative Name:
            email:[e-mail]
            X509v3 Subject Alternative Name:
            DNS:gw1.acme.com, DNS:*.ano.com, DNS:*.some.com
            X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
    Signature Algorithm: sha1WithRSAEncryption

The outgoing SIP INVITE (INVITE 2 in the diagram) would then look like the sample below. The INVITE is sent because smith.acme.com matches the common name *.acme.com. Other valid SIP Request-URIs would be:

[e-mail]
[e-mail]
[e-mail]

You can see where the system uses information from the certificate; the text is bold.

INVITE sip:[e-mail]:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.27.113:5060;branch=z9hG4bK4jmg29cmm8l0cg7smmrn85o4q7
From: 111111 <sip:[e-mail]>;tag=_ph1_tag
To: 222222 <sip:[e-mail]>
Call-ID: [e-mail]-1-
CSeq: 1 INVITE
Contact: <sip:111111@172.16.27.113:5060;transport=udp>
Max-Forwards: 69
Subject: TBD
Content-Type: application/sdp
Content-Length: 138
Route: <sip:222222@172.16.27.188:5060;lr>
v=0
o=user1 53655765 2353687637 IN IP4 172.16.27.113
s=-
c=IN IP4 172.16.27.113
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000