This is a static archive of our old Q&A Site. Please post any new questions and answers at

Unknown CA site


I have analyzed the comunication from my server to site credemtel and I have one anomaly. In source my server and destination credemtel server I have "Alert (level: Fatal, Description: Unknown CA)". What does this mean? The server does not recognize CA to the site credemtel? What should I do?

Thank you. Best regard


asked 20 Jul '17, 02:47

Riccardo1987's gravatar image

accept rate: 0%

edited 21 Jul '17, 06:14

cmaynard's gravatar image

cmaynard ♦♦


My wild guess would be that the sender of that Alert message did not like the other party's certificate because the latter refers to an unknown Certification Authority (CA). As you haven't provided the capture, I don't know which side complains, so I cannot suggest what to do.

(20 Jul '17, 04:48) sindy

Hi Sindy, where can i send you the capture?

(21 Jul '17, 02:26) Riccardo1987

Can you share a capture in a publicly accessible spot, e.g. CloudShark, Google Drive, DropBox etc?

(21 Jul '17, 02:44) grahamb ♦

I activate cloudshark . The ip destination is ip.addr == . The site for view packet is

Thank you

(21 Jul '17, 03:04) Riccardo1987

One Answer:


The certificates all look good to me, I suspect that there is an issue on the client machine where it's unable to verify the certificate chain.

I (on Windows) extracted the certificates using tshark and then converted the hex strings to binary with PowerShell and then used certutil to verify:

# Use tshark to extract the certificate bytes
$x = tshark -r pi.cap -Y "frame.number == 201" -T fields -e ssl.handshake.certificate

split the certs at the comma

$c1, $c2, $c3 = $x -split ",+"

Convert strings of "xx:xx…" to bytes in a binary array

$b1 = @( $c1 -split ":+" | foreach-object { [System.Convert]::ToByte($,16) } ) $b2 = @( $c2 -split ":+" | foreach-object { [System.Convert]::ToByte($,16) } ) $b3 = @( $c3 -split ":+" | foreach-object { [System.Convert]::ToByte($_,16) } )

Output the byte arrays to files

$b1 | Set-Content -Encoding Byte -Path cert1.der $b2 | Set-Content -Encoding Byte -Path cert2.der $b3 | Set-Content -Encoding Byte -Path cert3.der

Use certutil to verify the cert chain

certutil -verify cert1.der cert2.der certutil -verify cert2.der cert3.der

Use certutil to very the root CA cert

certutil -verify cert3.der

answered 21 Jul ‘17, 07:46

grahamb's gravatar image

grahamb ♦
accept rate: 22%

The problem is on server

(21 Jul ‘17, 08:01) Riccardo1987

Yes. Whatever software is running there is unable to verify the certifcate chain.

(21 Jul ‘17, 08:09) grahamb ♦

Sorry Grahamb, i am not expert in this argument. Can you send/share cert3.der?

Thank you so much.

(21 Jul ‘17, 08:45) Riccardo1987

Can you send/share cert3.der?

Not that doing so would be impossible, but if any root CA certificate should serve its purpose, you must never trust the one extracted from the certificate chain in server hello packet. Instead, you should obtain it via some other path, as the server operator might have forged it.

In this particular case, you have @grahamb’s word that he’s tested it (certutil checks a root certificate by locating it in the root certificate store on the machine where it is running), and you have no sane reason to assume that @grahamb acts in malicious agreement with the operator of the server which has provided that server hello packet, but in general this is a wrong way.

So what about downloading it from DigiCert’s web?

Could be a better idea, but remember, I may have myself forged both the web you are accessing and the whole DigiCert’s web.

So as for me, the best idea is to try to open that web on another machine within your reach which does have that DigiCert’s certificate pre-installed in its trusted CA certificate store, and if it works fine, to export the certificate from that machine’s trusted certificate store into a file and import that file on your machine.

(21 Jul ‘17, 09:30) sindy