Firefox and SSL: sec_error_unknown_issuer - firefox

My client gets a sec_error_unknown_issuer error message when visiting https://mediant.ipmail.nl with Firefox.
I can't reproduce the error myself. I installed FF on a Vista and a XP machine and had no problems. FF on Ubuntu also works fine.
Does anyone get the same error and does anyone have some clues for me so I can tell my ISP to change some settings?
The certificate is a so called wild-card SSL certificate that works for all subdomains (*.ipmail.nl). Was I wrong to pick the cheapest one?

Just had the same problem with a Comodo Wildcard SSL cert. After reading the docs the solution is to ensure you include the certificate chain file they send you in your config i.e.
SSLCertificateChainFile /etc/ssl/crt/yourSERVERNAME.ca-bundle
Full details on Comodo site

We had this problem and it was very much Firefox specific -- could only repro in that browser, Safari, IE8, Chrome, etc were all fine.
Fixing it required getting an updated cert from Comodo and installing it.
No idea what magic they changed, but it was definitely something in the cert that Firefox did NOT like.

For nginx do this
Generate a chained crt file using
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
The resulting file should be used in the ssl_certificate directive:
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
...
}

Firefox is more stringent than other browsers and will require proper installation of an intermediate server certificate. This can be supplied by the cert authority the certificate was purchased from. the intermediate cert is typically installed in the same location as the server cert and requires the proper entry in the httpd.conf file.
while many are chastising Firefox for it's (generally) exclusive 'flagging' of this, it's actually demonstrating a higher level of security standards.

I know this thread is a little old but we ran into this too and will archive our eventual solution here for others.
We had the same problem with a Comodo wildcard "positive ssl" cert.
We are running our website using a squid-reverse SSL proxy and Firefox would keep complaining "sec_error_unknown_issuer" as you stated, yet every other browser was OK.
I found that this is a problem of the certificate chain being incomplete. Firefox apparently does not have one of the intermediary certificates build in, though Firefox does trust the root CA. Therefore you have to provide the whole chain of certificates to Firefox. Comodo's support states:
An intermediate certificate is the
certificate, or certificates, that go between your site (server)
certificate and a root certificate. The intermediate certificate, or
certificates, completes the chain to a root certificate trusted by the
browser.
Using an intermediate certificate means that you must complete an
additional step in the installation process to enable your site
certificate to be chained to the trusted root, and not show errors in
the browser when someone visits your web site.
This was already touched on earlier in this thread but it did not resove how you do this.
First you have to make a chained certificate bundle and you do that by using your favorite text editor and just paste them in, in the correct (reverse) order i.e.
Intermediate CA Certificate 2 - IntermediateCA2.crt - on top of the
file
Intermediate CA Certificate 1 - IntermediateCA1.crt
Root CA Certificate - root.crt - at the end of the file
The exact order you can get from your ssl provider if its not obvious from the names.
Then save the file as whatever name you like. E.g. yourdomain-chain-bundle.crt
In this example I have not included the actual domain certificate and as long as your server can be configured to take a separate chained certificate bundle this is what you use.
More data can be found here:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/643/0/how-do-i-make-my-own-bundle-file-from-crt-files
If for some reason you can't configure your server to use a separate chained bundle, then you just paste your server certificate in the beginning (on the top) of the bundle and use the resulting file as your server cert. This is what needs to be done in the E.g Squid case. See below from the squid mailing list on this subject.
http://www.squid-cache.org/mail-archive/squid-users/201109/0037.html
This resolved it for us.

I had this problem with Firefox and my server. I contacted GoDaddy customer support, and they had me install the intermediate server certificate:
http://support.godaddy.com/help/article/868/what-is-an-intermediate-certificate
After a re-start of the World Wide Web Publishing Service, everything worked perfectly.
If you do not have full access to your server, your ISP will have to do this for you.

Which version of Firefox on which platform is your client using?
The are people having the same problem as documented here in the Support Forum for Firefox. I hope you can find a solution there. Good luck!
Update:
Let your client check the settings in Firefox: On "Advanced" - "Encryption" there is a button "View Certificates". Look for "Comodo CA Limited" in the list. I saw that Comodo is the issuer of the certificate of that domain name/server. On two of my machines (FF 3.0.3 on Vista and Mac) the entry is in the list (by default/Mozilla).

As #user126810 said, the problem can be fixed with a proper SSLCertificateChainFile directive in the config file.
But after fixing the config and restarting the webserver, I also had to restart Firefox. Without that, Firefox continued to complain about bad certificate (looks like it used a cached one).

If you got your cert from COMODO your need to add
this line, the file is on the zip file you received.
SSLCertificateChainFile /path/COMODORSADomainValidationSecureServerCA.crt

June 2014:
This is the configuration I used and it working fine after banging my head on the wall for some days. I use Express 3.4 (I think is the same for Express 4.0)
var privateKey = fs.readFileSync('helpers/sslcert/key.pem', 'utf8');
var certificate = fs.readFileSync('helpers/sslcert/csr.pem', 'utf8');
files = ["COMODORSADomainValidationSecureServerCA.crt",
"COMODORSAAddTrustCA.crt",
"AddTrustExternalCARoot.crt"
];
ca = (function() {
var _i, _len, _results;
_results = [];
for (_i = 0, _len = files.length; _i < _len; _i++) {
file = files[_i];
_results.push(fs.readFileSync("helpers/sslcert/" + file));
}
return _results;
})();
var credentials = {ca:ca, key: privateKey, cert: certificate};
// process.env.PORT : Heroku Config environment
var port = process.env.PORT || 4000;
var app = express();
var server = http.createServer(app).listen(port, function() {
console.log('Express HTTP server listening on port ' + server.address().port);
});
https.createServer(credentials, app).listen(3000, function() {
console.log('Express HTTPS server listening on port ' + server.address().port);
});
// redirect all http requests to https
app.use(function(req, res, next) {
if(!req.secure) {
return res.redirect(['https://mydomain.com', req.url].join(''));
}
next();
});
Then I redirected the 80 and 443 ports:
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 4000
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 3000
As you can see after checking my certifications I have 4 [0,1,2,3]:
openssl s_client -connect mydomain.com:443 -showcerts | grep "^ "
ubuntu#ip-172-31-5-134:~$ openssl s_client -connect mydomain.com:443 -showcerts | grep "^ "
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Protocol : TLSv1.1
Cipher : AES256-SHA
Session-ID: 8FDEAEE92ED20742.....3E7D80F93226142DD
Session-ID-ctx:
Master-Key: C9E4AB966E41A85EEB7....4D73C67088E1503C52A9353C8584E94
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 7c c8 36 80 95 4d 4c 47-d8 e3 ca 2e 70 a5 8f ac |.6..MLG....p...
0010 - 90 bd 4a 26 ef f7 d6 bc-4a b3 dd 8f f6 13 53 e9 ..J&..........S.
0020 - f7 49 c6 48 44 26 8d ab-a8 72 29 c8 15 73 f5 79 .I.HD&.......s.y
0030 - ca 79 6a ed f6 b1 7f 8a-d2 68 0a 52 03 c5 84 32 .yj........R...2
0040 - be c5 c8 12 d8 f4 36 fa-28 4f 0e 00 eb d1 04 ce ........(.......
0050 - a7 2b d2 73 df a1 8b 83-23 a6 f7 ef 6e 9e c4 4c .+.s...........L
0060 - 50 22 60 e8 93 cc d8 ee-42 22 56 a7 10 7b db 1e P"`.....B.V..{..
0070 - 0a ad 4a 91 a4 68 7a b0-9e 34 01 ec b8 7b b2 2f ..J......4...{./
0080 - e8 33 f5 a9 48 11 36 f8-69 a6 7a a6 22 52 b1 da .3..H...i....R..
0090 - 51 18 ed c4 d9 3d c4 cc-5b d7 ff 92 4e 91 02 9e .....=......N...
Start Time: 140...549
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Good luck!
PD: if u want more answers please check: http://www.benjiegillam.com/2012/06/node-dot-js-ssl-certificate-chain/

If anyone else is experiencing this issue with an Ubuntu LAMP and "COMODO Positive SSL" try to build your own bundle from the certs in the compressed file.
cat AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt > YOURDOMAIN.ca-bundle

I've being going round in circles with Firefox 43, El Capitan and WHM/cPanel SSL installation continually getting the Untrusted site error - I didn't buy the certificate it was handed over to me to install as the last guy walked out the door. Turns out I was installing under the wrong domain because I missed off the www - but the certificate still installed against the domain, when I installed the certificate in WHM using www.domain.com.au it installed now worries and the FF error has gone - the certificate works fine for both www and non-www.

To answer the non-reproducability aspect of the question - Firefox automatically imports intermediate certificates into its certificate store. So if you've previously visited a site which has used the same Intermediate Certificate using a correctly configured certificate chain then Firefox will store that Certificate so you will not see the problem when you visit a site that has an incorrectly configured chain using the same Intermediate certificate.
You can check this in Firefox's Certificate Manager (Options->Privacy&Security->View Certificates...) where you can see all stored certificates. Under the 'Security Device' Column you can check where a certificate has come from - automatically/manually imported certificates will appear as from 'Software Security Device' as opposed to the 'Builtin Object Token', which are the default set installed with Firefox. You can delete/Distrust any specific certificates and test again.

Had same issue this end of week, only Firefox will not accept certificate... The solution for me has been to add, in the apache configuration of the website, the intermediate certificate with the following line :
SSLCACertificateFile /your/path/to/ssl_ca_certs.pem
Find more infomration on https://httpd.apache.org/docs/2.4/fr/mod/mod_ssl.html

Related

Windows 7, Digitally signed driver shows warning : Windows cant verify the publisher of this driver software

I am trying install a windows USB driver with a simple structure (containing only the following content -
app.inf,
app.cat
WdfCoInstaller01005.dll
WinUSBCoInstaller.dll
).
The driver is sha 256 signed using a valid standard kernel mode code signing certificate issued by Digicert. I could see the digital signature in the app.cat file when I am see the properties of the file.
I am trying to install the driver via install-shield setup in the Windows 7 SP1 64 Bit machine with all latest updates installed( including KB3033929). It still shows the warning Windows cant verify the publisher of this driver software.
For troubleshooting this I have tried installing the certificate in the target machine as one of the Stackoverflow link suggests. Still no hope.
I have used the following commands during the process of generating the .cat file and signing the .cat file. (There is no .sys file)
Inf2Cat /driver:"C:\CodeSigning" /os:7_X64,7_X86
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64>signtool.exe si
gn /v /ac "C:\CodeSigning\DigiCert High Assurance EV Root CA.crt" /a /t ht
tp://timestamp.digicert.com "C:\CodeSigning\Driver\app.cat"
EDIT Adding more information.
I have tried Sha256 Signing also (Referring from https://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm (section :Internet Explorer or Chrome for Windows)
signtool sign /v /ac "C:\path\DigiCert High Assurance EV Root CA.crt" /a /tr http://timestamp.digicert.com /td sha256 /fd sha256 "c:\path\to\FileToSign.cat"
Still I am getting the same error.
EDIT 2- Adding the source of the Inf file
Please refer the source of the .inf file below (Could be little legacy).
[Version]
Signature = "$Windows NT$"
Class =XYZdevice
ClassGuid={ad769fbf-c592-4b8c-940a-6e3782a545e8}
Provider = %ProviderName%
DriverVer=10/13/2017,6.00.2064
CatalogFile=%MFGFILENAME%.cat
; ========== Manufacturer/Models sections ===========
[Manufacturer]
%ProviderName% = XYZInc,NTx86,NTamd64
[XYZInc.NTx86]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_1448&PID_4AC0&REV_0001
[XYZInc.NTamd64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_1448&PID_4AC0&REV_0001
; =================== Installation ===================
[ClassInstall32]
AddReg=SampleClass_RegistryAdd
[SampleClass_RegistryAdd]
HKR,,,,%ClassName%
;[1]
[USB_Install]
Include=winusb.inf
Needs=WINUSB.NT
;[2]
[USB_Install.Services]
Include=winusb.inf
AddService=WinUSB,0x00000002,WinUSB_ServiceInstall
;[3]
[WinUSB_ServiceInstall]
DisplayName = %WinUSB_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys
;[4]
[USB_Install.Wdf]
KmdfService=WINUSB, WinUsb_Install
[WinUSB_Install]
KmdfLibraryVersion=1.5
;[5]
[USB_Install.HW]
AddReg=Dev_AddReg
[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{15630179-b622-4834-8ff7-9916b1446884}"
;[6]
[USB_Install.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles
[CoInstallers_AddReg]
HKR,,CoInstallers32,0x00010000,"WdfCoInstaller01005.dll,WdfCoInstaller","WinUSBCoInstaller.dll"
[CoInstallers_CopyFiles]
WinUSBCoInstaller.dll
WdfCoInstaller01005.dll
[DestinationDirs]
CoInstallers_CopyFiles=11
; ================= Source Media Section =====================
;[7]
[SourceDisksNames]
1 = %DISK_NAME%,,,\i386
2 = %DISK_NAME%,,,\amd64
[SourceDisksFiles.x86]
WinUSBCoInstaller.dll=1
WdfCoInstaller01005.dll=1
[SourceDisksFiles.NTamd64]
WinUSBCoInstaller.dll=2
WdfCoInstaller01005.dll=2
; =================== Strings ===================
[Strings]
MFGFILENAME="XYZDevice"
ProviderName="XYZ Inc"
ClassName="XYZ device"
USB\MyDevice.DeviceDesc="XYZ"
WinUSB_SvcDesc="XYZ"
DISK_NAME="Drivers"
I have verified the counter signature details also. Please refer the image below.
Thumbprint of the certificate used for cross signing (thumbprint: 2f 25 13 af 39 92 db 0a 3f 79 70 9f f8 14 3b 3f 7b d2 d1 43 cross-certificate for DigiCert High Assurance EV Root CA)
Thumbprint of the cross signed certificate which can be seen from the properties of the signed file is ‎40 01 91 47 5c 98 89 1d eb a1 04 af 47 09 1b 5e b6 d4 cb cb
(I dont know whether it is correct or not)
Please help. I have spent plenty of time on this and still end up with no results. Any help on this would be really appreciable.

Windows Machine Cert File Mappings

BLUF
If you know a windows machine certificate file name, can you view the file contents in the windows certificate store?
Background
I am working with the Windows 7+ VPN Client. It does not let you directly select the certificate that should be used for a connection and provides very limited feedback. The most notorious error RRAC is 13801 that roughly sums up to 'I don't like something about a certificate being used, but i am not going to tell you what exactly'.
Using the Event Viewer to view Security entries, I do see that there is a request for a certificate. Something like:
ProviderName Microsoft Software Key Storage Provider
AlgorithmName UNKNOWN
KeyName {#################}
KeyType %%2499
KeyFilePath C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\<filename>
Operation %%2458
ReturnCode 0x0
I was wondering how i could use the filename mentioned above to view the certificate properties (IE: see that the one i want is being used). Right now my only method is to import a certificate via mmc and see the new file being created at the time of import. I cannot use this trick for certificates that are already imported on the system.
All of the identifiers here are for the private key. The private key doesn't know where the certificate lives, because the architecture is that the cert object / cert store know where the private key is for a given certificate.
To see the mapping between certs in a cert store and the keys on the system you can use certutil -store, e.g.:
C:\>certutil -store my
my
================ Certificate 0 ================
...
================ Certificate 7 ================
Serial Number: 3451b93c10f9279348a949f729d1ff10
Issuer: CN=localhost
NotBefore: 1/26/2015 2:19 PM
NotAfter: 1/25/2020 4:00 PM
Subject: CN=localhost
Signature matches Public Key
Root Certificate: Subject matches Issuer
Template:
Cert Hash(sha1): 15 e3 4c d3 2d a7 54 99 a9 17 8f 17 26 25 63 25 8f 3a 94 28
Key Container = IIS Express Development Certificate Container
Unique container name: fad662b360941f26a1193357aab3c12d_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd
Provider = Microsoft RSA SChannel Cryptographic Provider
Encryption test passed
CertUtil: -store command completed successfully.
Where the thing to match is Key Container in this output is the same as KeyContainerName in the event, and Provider in this output is ProviderName in the event.
You can also dump the user store (the default is the machine):
C:\>certutil -user -store -silent my
my
================ Certificate 0 ================
Serial Number: 0123456789abcdef
Issuer: E=issueremail#example.org, CN=cn.issuer.example.org, OU=ExampleOU, O=ExampleO, L=Locality, S=State, C=Country
NotBefore: 11/12/2013 6:15 AM
NotAfter: 12/13/2014 7:16 AM
Subject: E=subjectemail#example.org, CN=cn.subject.example.org, OU=ExampleOU, O=ExampleO, L=Locality, S=State, C=Country
Non-root Certificate
Template:
Cert Hash(sha1): ff 3d 35 54 54 fd ff ea 52 cd 71 6f e7 14 24 75 3f f7 fe cf
Key Container = {F76693EF-BDC3-4AEC-855A-3A2F65EB9C14}
Unique container name: 0148994a057f4e05acb6407550cdde40_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd
Provider = Microsoft Enhanced RSA and AES Cryptographic Provider
Private key is NOT exportable
Encryption test passed
...
================ Certificate 51 ================
Serial Number: 0123456789abcdef
Issuer: E=issueremail#example.org, CN=cn.issuer.example.org, OU=ExampleOU, O=ExampleO, L=Locality, S=State, C=Country
NotBefore: 11/12/2013 6:15 AM
NotAfter: 12/13/2014 7:16 AM
Subject: E=subjectemail#example.org, L=Locality, S=State, C=Country
Non-root Certificate
Template:
Cert Hash(sha1): 2a 81 f8 d1 c7 40 13 2f 15 5a 5e 30 41 1a 2b 13 71 93 db 9e
Key Container = {2572D484-D352-4B32-BB00-236B755B7F81}
Unique container name: b11d717c1718a3bc6ad1769f2226998e_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd
Provider = Microsoft Enhanced RSA and AES Cryptographic Provider
Private key is NOT exportable
Encryption test passed
In addition to the -user switch I specified -silent, because I have some smartcard backed certificates and I didn't want to deal with getting prompted for the card and PIN.

How to update Update X509 certificates for On-Premise Service Fabric cluster

The documentation for updating x509 certificates in Service Fabric is unclear to me with regards to non-Azure (On-Prem) installations: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-upgrade-windows-server
I have followed these steps, but they have not worked.
Updated the cluster setup json template so that the thumbprint of the original certificate is now "ThumbprintSecondary".
Added the new certificate thumbprint under "Thumbprint". e.g.
"security": {
"metadata": "The Credential type X509 indicates this is cluster is
secured using X509 Certificates. The thumbprint format is - d5 ec 42 3b 79 cb e5 07 fd 83 59 3c 56 b9 d5 31 24 25 42 64.",
"ClusterCredentialType": "X509",
"ServerCredentialType": "X509",
"CertificateInformation": {
"ClusterCertificate": {
"Thumbprint": "New Thumbprint",
"ThumbprintSecondary": "Old Thumbprint",
"X509StoreName": "My"
},
"ServerCertificate": {
"Thumbprint": "New Thumbprint",
"ThumbprintSecondary": "Old Thumbprint",
"X509StoreName": "My"
},
Install the new certificate pfx and update the ACL for "NETWORK SERVICE"
Run Start-ServiceFabricClusterConfigurationUpgrade -ClusterConfigPath "Path to json Configuration File"
for your question, no there is no out of the box way to update Certificate for Service Fabric on-premise cluster.
I opened a ticket with Microsoft for this issue: 117011115158708 and they replied it will be fixed on version 5.5
this version is out now and the problem still not fixed, they should get back to me with an answer about this issue, i will try to keep this post updated.
Certificate update would be a cluster configuration change. The following method has worked for me for cluster configuration changes.
Install the new cert on all nodes as you've already done.
Run Get-ServiceFabricRegisteredClusterConfigVersion. The highest number
listed will most likely be the cluster config version you are on.
Run Get-ServiceFabricClusterManifest | Out-File C:\ClusterManifest.xml
Edit the ClusterManifest.xml file and make the following changes:
Upgrade the Version attribute on the root ClusterManifest XML tag
(e.g. if it is 1, go to 2)
Update the thumbprints under the Certificates section
Use Copy-ServiceFabricClusterPackage with -Config option (I have not included the full syntax but you can look that up as it is quite detailed) and specify the modified ClusterManifest.xml file.
Run Get-ServiceFabricRegisteredClusterConfigVersion. The version you just
uploaded will now be the highest version (e.g. 2 in this example).
Run Start-ServiceFabricClusterUpgrade -Config -ClusterManifestVersion
new-version (2 in this example; again I have left out other
parameters for simplicity).

Fix for Octave urlread causing Peer certificate cannot be authenticated with given CA certificates

Question
How to the fix (not workaround) for Octave (suppose libcurl bundled with octave) urlread causing Peer certificate cannot be authenticated with given CA certificates?
Having read pkg install from forge in windows, it looks the Octave maintainer is aware of the issue with Octave 4.0 but it seems no fix is available.
Issue
It looks the urlread of Octave on Windows does not work for HTTPS because the server certificate of such as https://octave.sourceforge.io cannot be authenticated with the trusted certificates which urlread (which seems to call curl) refers to.
For example, share\octave\4.2.0\m\pkg\private\get_forge_pkg.m line 64 is causing the issue when trying to run pkg install -forge to install packages.
## Try get the list of all packages.
[html, succ] = urlread ("http://packages.octave.org/list_packages.php");
if (! succ)
error ("get_forge_pkg: could not read URL, please verify internet connection");
endif
Running urlread from the command window shows the error below.
>> [html, status, msg] = urlread ("http://packages.octave.org/list_packages.php");
>> msg
msg = Peer certificate cannot be authenticated with given CA certificates
Tried google.com over HTTPS and the same.
>> [html, status, msg] = urlread ("https://google.com");
>> msg
msg = Peer certificate cannot be authenticated with given CA certificates
IE and Google Chrome root certificates can verify the sourceforge certificate.
Tried system as below.
#[html, succ] = urlread ("http://packages.octave.org/list_packages.php");
sURLLink="https://octave.sourceforge.io/list_packages.php"
command=['curl --insecure ','"',sURLLink,'"'];
[succ, html] = system(command)
#if (! succ)
if (succ != 0)
error ("get_forge_pkg: could not read URL, please verify internet connection");
endif
However it caused another error.
>> pkg install -forge symbolic
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 559 100 559 0 0 389 0 0:00:01 0:00:01 --:--:-- 393
sURLLink = https://octave.sourceforge.io/list_packages.php
succ = 0
html = bim
bsltl
cgi
....
error: get_forge_pkg: package NAME exists, but index page not available
error: called from
get_forge_pkg at line 74 column 7
get_forge_download at line 26 column 12
pkg at line 382 column 29
Related information
pkg install from forge in windows
urlread(), urlwrite() don't work for https pages in Octave for Windows
windows libcurl - peer certificate cannot be authenticated with given ca certificates
Getting error in Curl - Peer certificate cannot be authenticated with known CA certificates
SSL CA Certificates - LibCurl C Language (Linux)
Environment
octave-4.2.0-w64 on Windows 7 Enterprise 64 bit Version 6.1.7601 Service Pack 1 Build 7601
Octave 4.0.3 on Windows 10 Pro 64 bit Version 10.0.14393 Build 14393
You get the "Peer certificate cannot be authenticated" error because your CA store doesn't contain the necessary CA cert. You can get an updated bundle from here.
The reason your attempt to use the curl command line tool doesn't work is that you didn't use -L, --location option to tell curl to follow redirects, so you just got the 303 response that http://packages.octave.org/list_packages.php returns. If you'd use -L, you'll see that it'll redirect you twice over to a HTTPS:// URL - only to have you be forced to fix case (1) anyway.

Firefox ignores signature on successfully signed XPI - how to diagnose?

I've created a Firefox plugin, a Win32-native code DLL - using Firebreath. I'm working on Windows 7/x64, and targeting Windows only. The plugin itself is working well, but I'm really stuck getting a correctly signed XPI. If I don't sign my XPI, it's accepted and installed by FF 3.6 thru 10 (beta). Of course, during the install it lists the publisher as (Author not verified). So, I spent a week debugging the signing process... but FF 9 and 10 still say (Author not verified)! FF 3.6 rejects the signed XPI as invalid.
How do I troubleshoot this??
Just to repeat: I sign the xpi without error, and the resulting XPI installs successfully on FF 9 and 10, but FF still says (Author not verified).
Here's the batch code I use to sign the XPI:
echo * clean out old signing folder and xpi
if exist package rmdir /S /Q package
if exist %package%.xpi del %package%.xpi
echo * copy in files for package
md package
xcopy ..\*.rdf package
md package\plugins
xcopy ..\build\bin\Plugin\Debug\*.dll package\plugins
echo * clean out certificate database
del *.db
echo * import our signing certificate
pk12util -d . -i %keyfile% -K %pwd% -w keypass.txt
echo * adjust trust on base, intermediate and root cert
certutil -M -d . -n "VeriSign" -t "c,c,C"
certutil -M -d . -n "VeriSign Class 3 Code Signing 2010 CA - VeriSign, Inc." -t "TC,TC,TC"
certutil -M -d . -n "%certname%" -t "u,u,Cu"
certutil -L -d .
echo * create signed package
signtool -d . -X -Z %package%.xpi -k "%certname%" -p %pwd% package
I work for Mozilla, but this isn't an authoritative answer, just what I've gathered asking around:
So, essentially, each certificate authority has three trust bits Mozilla might grant it: they might trust it to sign websites, and/or mail, and/or code. Your certificate is from a certificate authority that Mozilla doesn't trust to sign code. (This is why going and manually setting the bit in your preferences makes it work—for you.)
I'm told so few people try to use binary code in xpi's that Mozilla doesn't really have an organized way to find out which authorities can be used for what. However, you can check out this list: look at the "Code Trust Bit":
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
For example (picked completely at random), ComSign Secured CA has the "Websites" and "Code" trust bits set.
I gather that Mozilla publicly discusses what rights to grant to each CA, and re-evaluates each CA periodically:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Basically your signature needs to include full certificate chain up to the trusted VeriSign root certificate, bypassing the "VeriSign Class 3 Public Primary Certification Authority - G5" with unknown trust in mozilla (bug 602107), as by default the chain ends too soon.
Your XPI is currently signed with your certificate, with no further certificate chain included, relying that the user's browser will trust the issuer of your certificate immediately. You can examine this with Mozilla's jarsigner tool (see Mozilla NSS tools):
Tools\nss-3.11>jarsigner -verify -verbose -certs my-old.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
(showing just the output for the 1st file)
You need to include a few more certificates to complete the chain to a certificate that is by default explicitly trusted in the end user's browser. In the end it should look like this:
jarsigner -verify -verbose -certs my-newly-signed.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
X.509, CN=VeriSign Class 3 Code Signing 2010 CA, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.2.10 1:00 to 8.2.20 0:59]
[KeyUsage extension does not support code signing]
X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.11.06 1:00 to 8.11.21 0:59]
[KeyUsage extension does not support code signing]
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 23.5.06 19:01 to 23.5.16 19:11]
To achieve this you need to:
remove the not-explicitly-trusted VeriSing's built-in certificates from the certificate database with Mozilla's certutil tool
Build the certificate trust chain of your certificate all the way up to Microsoft's "Class 3 Public Primary Certification Authority".
sign the xpi (this time full certificates chain will be included in the signature)
verify the xpi with jarsigner as described above
test the xpi in Firefox - you should not see "Author not verified" anymore.
Caveats:
Trust bits in the built-in Firefox certificate store are actually 3-state (trusted, untrusted and unknown), despite only being shown as 2-state checkbox in the FF GUI (checked=trusted, unchecked=untrusted OR unknown). By default trust is unknown, which enables you to bypass the VeriSign's certificate as described. If you ever enabled trust via FF's checkboxes it will still work, but if you uncheck the trust checkbox the trust will be set to untrusted, which will prevent bypassing that certificate in the chain. The easiest (only?) way to reset this back to initial unknown is to delete your firefox profile.
After Mozilla eventually enables the code-signing trust bit (see the bug above) you will still need to sign like this if you want to support older versions of Firefox.
Hope it helps!

Resources