On Mon, 2010-02-22 at 13:29 -0500, Carolyn Beeton wrote:
> I am working on an alarm when a TLS connection is blocked because the
> certificate identity (the subjAltName) does not resolve to the same IP
> address as the request was sent to:
>
> Subject: Alarm SPX00041: The certificate identity does not match the
> request address
> Message from sipXecs
> Alarm: SPX00041
> Reported on: cbeetonscs.ca.nortel.com
> Reported at: 2010-02-22T18:18:06.092322Z
> Severity: CRIT
> Alarm Text: The expected address is
> bcmdesk2041.ca.nortel.com(47.135.152.41), but the certificate contains
> the following identities: bcmdesk2041.com
> Suggested Resolution: This is a security violation because the identity
> encapsulated in the remote certificate does not match the address it
> came from. Ensure that the certificate identity resolves to the request
> address.
>
> Does this look correct? Clear?
I wouldn't confuse the issue by using the term 'address' in the alarm
text.
Alarm Text: The configuration requires the identity
'bcmdesk2041.ca.nortel.com', but the remote certificate contains
only the following identities: bcmdesk2041.com
> I have thought about raising an INFO alarm when the identity contained
> in the TLS certificate does not map to an internal TLS Peer. There is
> nothing really wrong with this; it just means that users of the remote
> system will not be assigned permissions and will not be allowed access
> to resources which require permissions; but it can be tricky to figure
> out what the TLS Peer name should be, so this alarm would list the
> identities contained in the certificate:
>
> Subject: Alarm SPX00042: The certificate identity does not map to a TLS
> Peer
> Message from sipXecs
> Alarm: SPX00042
> Reported on: cbeetonscs.ca.nortel.com
> Reported at: 2010-02-22T18:18:06.092322Z
> Severity: INFO
> Alarm Text: The identities contained in the TLS certificate do not map
> to a TLS Peer: bcmdesk2041.com
> Suggested Resolution: This means that users of the remote system will
> not be assigned permissions and will not be allowed access to resources
> which require permissions. If desired, create a TLS Peer using one of
> the certificate identities.
I'm concerned that this could generate a lot of alarms if something
(like a phone) opens and closes connections frequently. I think that
it's sufficient to log the identities at INFO level so that they can be
found when someone is trying to debug inbound requests.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
