cert_override.txt format
Aditya Ivaturi
one I should post in, thanks.
We use Selenium for web testing automation. And one of the biggest
problems we face with Selenium is handling of self signed certificates
(we use self-signed certs for daily builds). There are alternatives
that do work, but they are not a good solution for as with every build
our certificates change.
Another simple & probably effective solution is to populate the
cert_override.txt & cert8.db with the relevant self-signed cert &
continue with our automation uninterrupted. This page -
https://developer.mozilla.org/En/Cert_override.txt - describes the
format of cert_override.txt and I can use openssl to get the first 4
parts of cert_override.txt. But I am having problems with the 5th part
- "Certificate's serial number and the issuer name as a base64 encoded
string". I can get the cert's serial number & issuer name usign
openssl, but a simple base64 encoding of those values doesn't seem to
be right. Can any one please tell me (or point me to a location) how
this magic string is generated?
Johnathan Nightingale
not the ASCII representation output by openssl. That is, you don't
want to base64 the _string_ "08 BE 4F..." you want to base64 encode
the binary byte array with values 0x08, 0xBE, 0x4F, etc.
Does that help?
Cheers,
Johnathan
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
---
Johnathan Nightingale
Human Shield
joh...@mozilla.com
Sid Stamm
>> - "Certificate's serial number and the issuer name as a base64 encoded
>> openssl, but a simple base64 encoding of those values doesn't seem to
>> be right. Can any one please tell me (or point me to a location) how
>> this magic string is generated?
> the ASCII representation output by openssl. That is, you don't want to
> base64 the _string_ "08 BE 4F..." you want to base64 encode the binary
> byte array with values 0x08, 0xBE, 0x4F, etc.
Johnathan is right on. I think you need to generate a base64-encoded
version of the binary values (not the textual serializations). I did
something similar when playing with EV certificates, and the method I
used to get these encoded values involved patching NSS tools to spit
them out.
I wrote up some rough "how to install an ev root" instructions a while
back here, including how to get those encoded values:
http://evssl-trust.sidstamm.com/firefox-evca.html#patch-source
* You need to check out the NSS source and patch it to spit out b64
encodings of those values. Use the second patch listed at the link above
(http://evssl-trust.sidstamm.com/pp.patch), the first patch is
unnecessary for this purpose.
http://evssl-trust.sidstamm.com/firefox-evca.html#build-nss
* Then build the tools.
http://evssl-trust.sidstamm.com/firefox-evca.html#install-ca-and-ev
* The first couple of steps in this section explain how to get the
encoded values.
Hope this is helpful.
-Sid
Nelson Bolyard
> If my question doesn't belong in this group, please let me know which
> one I should post in, thanks.
>
> We use Selenium for web testing automation. And one of the biggest
> problems we face with Selenium is handling of self signed certificates
> (we use self-signed certs for daily builds). There are alternatives
> that do work, but they are not a good solution for as with every build
> our certificates change.
Why not set yourself up with a little CA, and issue all your certs from
it? That's what NSS QA test scripts do. It's no harder to issue real
certs from your real CA than to issue self-signed certs, and the results
are infinitely simpler to deal with. You probably use a single command
line command to issue your self signed certs. With a different single
comment (probably using the very same tool) you could be issuing certs
that have NO need of any invalid cert overrides.
Nelson Bolyard
s/comment/command/
sorry
Aditya Ivaturi
> Johnathan is right on. I think you need to generate a base64-encoded
> version of the binary values (not the textual serializations).
Based on this blog post here http://www.jessies.org/~car/blog/200907081926-for-firefox-sake.php,
it is actually base64 encoding of a block of memory - a long int
containing the der representation of serial number and the issuer
name. Chris's (the author of that blog post) hack produces the exact
notation of the string that you see in the cert_override.txt under
your profile directory. So it is the nsNSSCertificate::GetDbKey() that
actually generates that string for you.
> I did
> something similar when playing with EV certificates, and the method I
> used to get these encoded values involved patching NSS tools to spit
> them out.
>
I did try your patch and it produced the base64 output as you
mentioned. But it was different from the format that you see in
cert_override.txt, where that magic string starts with a sequence of
"AAAA...". But interestingly enough, your string also worked. When I
injected the self-signed cert in to cert8.db & populated the
cert_override.txt with your magic string output from pp, firefox
accepted it! So now, this throws another wrench in my understanding of
how FF actually deals with cert_override. Does the exact format the
magic string actually matter? Or does firefox just check for the
certificate in its cert store (cert8.db) & verify cert fingerprint in
cert_override.txt and allow access to the site?
Aditya Ivaturi
> Why not set yourself up with a little CA, and issue all your certs from
> it?
I should have qualified my query with more info. We are testing
Juniper SSL VPN box, which can be configured via browser only - hence
"web testing" automation in our case. So these daily builds are
presented to us as a single package. And when you install a new build,
a new self-signed cert is generated. If you need to install a real
cert, you have to browse to the relevant admin page & install this
cert. But all of this happens on https, that means you have to accept
the self-signed cert atleast once before you can install the real
cert. And in case of selenium the battle is already lost and hence
this whole exercise. Most of our test bed is virtualized with Vmware
Lab Manager - that means all the client machines images are deployed
at runtime. We could probably circumvent this issue by sticking with a
single vpn box and single client machine and run all our tests with
incremental builds. But that'd defeat a very important goal of our
automation framework - a dynamic test bed.
Sid Stamm
> mentioned. But it was different from the format that you see in
> cert_override.txt, where that magic string starts with a sequence of
> "AAAA...". But interestingly enough, your string also worked. When I
> cert_override.txt with your magic string output from pp, firefox
> accepted it! So now, this throws another wrench in my understanding of
> how FF actually deals with cert_override. Does the exact format the
> magic string actually matter? Or does firefox just check for the
> cert_override.txt and allow access to the site?
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCertOverrideService.cpp#259
This is a bit of NSS that reads the cert_override.txt file in case you
want to investigate it more. If it has to do with the flurry of A's at
the beginning (present in one string and not the other), I think they
might just be leading zeroes or padding or something. Since A = 0 in
Base64, perhaps the binary data scheme allows these leading zeroes,
stripping them out during decoding. If that's the case, you could end
up with different-looking encoded strings with the same canonical
decoded value -- some with A's at the beginning, and some without.
I'm not an expert in this bit of code, however, so I'm just making a
half-educated guess here. However, I'm pretty sure the "magic string's"
contents (b64-encoded stuff) does indeed matter for cert override. It
is used by the code referenced above, and it seems to have a comparison
method here:
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCertOverrideService.cpp#718
The actual format of the encoded string may not matter, so long as it
decodes to an equivalently valid key.
-Sid
Nelson Bolyard
> http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCertOverrideService.cpp#259
>
> This is a bit of NSS that reads the cert_override.txt file
It's not NSS. If it was NSS, you would see /nss/ in the path name above.
It's PSM, and the format of the file is a private interface, which means
that it could change at any time in any release or any update. So, just
be aware of that, and don't be upset if it changes.
Sid Stamm
Oops... my bad, sorry Nelson.
-Sid
Aditya Ivaturi
> It's not NSS. If it was NSS, you would see /nss/ in the path name above.
> It's PSM, and the format of the file is a private interface, which means
> that it could change at any time in any release or any update. So, just
> be aware of that, and don't be upset if it changes.
There is an active feature request in Selenium project to handle the
self-signed certificate issue. So this is more or less an interim
solution for us.