Stir/Shaken: my Identity signatures are invalid

Asterisk Asterisk Support
1

Hello,

I’m having a Stir/Shaken attestation issue.
With several ITSP I’m trunking with, my Identity is considered by their system as invalid.

My stir_shaken.conf attestation section only includes three settings:

  • a path to my private key file
  • a public cert URL
  • the default attestation level

How can I double check the Identity value I’m sending out ?

I tried using jwt.io website but I’m hesitant about the steps to follow.

Best regards

2

It would help to know why they think it’s invalid.

If you capture an outgoing INVITE message using either wireshark or by setting pjsip set logger host <remote_host> in the Asterisk CLI you should be able to extract the Identity header. Here’s an abbreviated example:

Identity: eyJhbGciOiJFUz...jZXJ0LnBlbSJ9.eyJhdHRlc3QiOiJ...ZjkxMCJ9.oIiingMf0...kl4Qt_vYw;info=<http://pbx.sample.net/ss_ca/intermediate/certs/server4.cert.pem>;alg=ES256;ppt=shaken

Copy everything after the Identity: up to but not including the ;info= and paste that into the jwt.io “Encoded” area. You should then see the decoded header and payload on the right. Now download your public certificate from the URL in the header and copy the contents into the top “Verify Signature” box. You don’t need the private key. At the bottom, you should now see “Signature Verified”. If it still says “Invalid Signature” at the bottom, then the certificate retrieved doesn’t match the private key specified in the attestation section.

3

Thank you very much for looking at this !

  1. When you write “but not including the ;info=”, shall I exclude the last “;” or leave it inside the Encoded field ?
  2. My public cert is a *.cer file in PEM format, starting with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE-----. Shall I include both startin and ending lines ?
4

The last ; can be included. It’ll be ignored.
Yes, include the BEGIN CERTIFICATE and END CERTIFICATE lines

5

Partial Identity value is:

eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9hcGkubWFuLWJwY28uZnIvY2VydHMvQURJUzAwLzE1MjZmNTQwMWRjYWIxMzcuY2VyIn0.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIzMzE0NzkwMzUxMSJdfSwiaWF0IjoxNzI3MTg3Njk2LCJvcmlnIjp7InRuIjoiMzMxODU4OTk5OTkifSwib3JpZ2lkIjoiNTZkYTVmNjItYzE2Yy00ZTAwLThhMTctMDA2ODRkOTgxOTBlIn0.FgPshmnLsdeMTrfn6bzd1_bG9tl2gJYDZiONhCxRtnXJHclOHgAaqvvL2fHMSJJGUMLN0VEqTx-EWHn1Q5TbBw;i

While public cert is:

-----BEGIN CERTIFICATE-----
MIIDjDCCAzKgAwIBAgIIFSb1QB3KsTcwCgYIKoZIzj0EAwIwgYExJzAlBgNVBAMM
HkJQQ08gQ0ExIC0gU0hBS0VOIEludGVybWVkaWF0ZTEpMCcGA1UECgwgQmFzZSBk
ZXMgQ2VydGlmaWNhdHMgT3DDqXJhdGV1cnMxHjAcBgNVBAsMFUNlcnRpZmljYXRl
IEF1dGhvcml0eTELMAkGA1UEBhMCRlIwHhcNMjQwNzI4MjIwMDAwWhcNMjUwNzI4
MjE1OTU5WjBDMRYwFAYDVQQDDA1TSEFLRU4gQURJUzAwMRwwGgYDVQQKDBNPcMOD
wqlyYXRldXIgQURFTklTMQswCQYDVQQGEwJGUjBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABHz13tf/TN3RBIJpKrJhi6RIAcvOjeMUQAoUhYA1U27VlMyMwgZu6DZ+
4ySRMLaV/PHkPhYAj3vPNaxhnqRWlzCjggHPMIIByzAMBgNVHRMBAf8EAjAAMB8G
A1UdIwQYMBaAFHCUt37l/PCkwEJoWCmCz102HNLHMEMGCCsGAQUFBwEBBDcwNTAz
BggrBgEFBQcwAoYnaHR0cHM6Ly9hcGkubWFuLWJwY28uZnIvY2EvY2VydHMvMTUu
Y2VyMIIBCgYDVR0fBIIBATCB/jCBjaAfoB2GG2h0dHBzOi8vYXBpLm1hbi1icGNv
LmZyL2NybKJqpGgwZjERMA8GA1UEAwwIQlBDTyBQQTExKTAnBgNVBAoMIEJhc2Ug
ZGVzIENlcnRpZmljYXRzIE9ww6lyYXRldXJzMRkwFwYDVQQLDBBQb2xpY3kgQXV0
aG9yaXR5MQswCQYDVQQGEwJGUjBsomqkaDBmMREwDwYDVQQDDAhCUENPIFBBMjEp
MCcGA1UECgwgQmFzZSBkZXMgQ2VydGlmaWNhdHMgT3DDqXJhdGV1cnMxGTAXBgNV
BAsMEFBvbGljeSBBdXRob3JpdHkxCzAJBgNVBAYTAkZSMB0GA1UdDgQWBBTRu1Yp
fbNqe3XDhhlP001TZrcnijAOBgNVHQ8BAf8EBAMCB4AwGAYIKwYBBQUHARoEDDAK
oAgWBkFESVMwMDAKBggqhkjOPQQDAgNIADBFAiA4rPlWCw889pW6k0b1BM9zSGu3
5UMaxF0lOOCh/jq2DAIhANJaIBb9c2CfNF0tzb9R7CUkfSjocYGNUhOG9Ki1wIA6
-----END CERTIFICATE-----

Using both in jwt.io debugger, I’ve got an invalid signature.
Maybe my public cert doesn’t match the private key I attested with ?

6

Actually, you do have to remove the trailing ; so when you paste your identity header into jwi.io it should only be…

eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9hcGkubWFuLWJwY28uZnIvY2VydHMvQURJUzAwLzE1MjZmNTQwMWRjYWIxMzcuY2VyIn0.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIzMzE0NzkwMzUxMSJdfSwiaWF0IjoxNzI3MTg3Njk2LCJvcmlnIjp7InRuIjoiMzMxODU4OTk5OTkifSwib3JpZ2lkIjoiNTZkYTVmNjItYzE2Yy00ZTAwLThhMTctMDA2ODRkOTgxOTBlIn0.FgPshmnLsdeMTrfn6bzd1_bG9tl2gJYDZiONhCxRtnXJHclOHgAaqvvL2fHMSJJGUMLN0VEqTx-EWHn1Q5TbBw

I just tried it and It does look like you have a mismatch between your private key and certificate so double check that the certificate you’re hosting on your web site is actually the correct certificate for the private key you’re using.

7

Changing my new public URL to an old one changed validation on jwt.io from failure to success, probably to an inconsistency between my public and private keys.

Crypto is hard to understand.

8

After digging further, I now have two different sets of public/private keys to attest outgoing traffic. Thanks again for your help.

As I incorrectly associated a private key with the wrong public key (or vice versa), would it possible if Asterisk could check if both public/private keys are compatible with each other and notify sysadmin in case of inconsistency ?
Asterisk cannot bear the burden of checking every setting but, IMHO, crypto is so error prone, a safety net would very much appreciated.

9

That’s a good idea. Open an improvement issue for it at Issues · asterisk/asterisk · GitHub

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.