I developed a kernel-mode driver and signed it with a "standard" code signed certificate because at this time I do not know about Win 10 driver signing.
I tested the driver on many systems from Win7 up to different Win10 machines (real machines and VMs too). The curious thing is: the driver works well on every test setup.
Now, I got some reports that the driver doesn't work on some Win10 machines due to a singning problem.
I tried to install the driver on my own machine and discovered the same problem:
Installation using dpinst works without problems. But the Device Manager shows
Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)
Verifying the driver using signtool for kernel mode divers states:
> .\signtool.exe verify /kp driver.cat
File: C:\Users\...\driver.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 1CF4B984575F15AC0A2CAF3C3B138F8B58867E35
Signing Certificate Chain:
Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
Expires: Thu Jul 17 01:59:59 2036
SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5
Issued to: Symantec Class 3 SHA256 Code Signing CA
Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
Expires: Sun Dec 10 01:59:59 2023
SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5
Issued to: #############
Issued by: Symantec Class 3 SHA256 Code Signing CA
Expires: Tue Mar 21 01:59:59 2023
SHA1 hash: C0AF3235EF9FAABE789A306C4AC9F20E80DE7BDB
The signature is timestamped: Wed Apr 27 09:56:50 2022
Timestamp Verified by:
Issued to: DigiCert Trusted Root G4
Issued by: DigiCert Trusted Root G4
Expires: Fri Jan 15 14:00:00 2038
SHA1 hash: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
Issued to: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
Issued by: DigiCert Trusted Root G4
Expires: Mon Mar 23 01:59:59 2037
SHA1 hash: B6C8AF834D4E53B673C76872AA8C950C7C54DF5F
Issued to: DigiCert Timestamp 2022 - 2
Issued by: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
Expires: Tue Mar 15 01:59:59 2033
SHA1 hash: 8508F386515CB3D3077DB6B4B7C07F1B4A5E41DE
SignTool Error: The signing certificate is not valid for the requested usage.
Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1
If I'm right, I need a EV code signing certificate to sign the driver for Win10?
If yes, the result of the verification using signtool is not unexpected.
Nevertheless - I'm confused because I can install and run the driver on serveral Win10 test machines without any problem. It seems that there is no difference if the system is up-to-date or not. There are x86 and x64 systems, Home and Pro versions, activated and not-activated setups. On almost all devices the driver still works very well.
That means it is not really necessary to use a "specific" certificate or messed I something up?
The different behaviour of the test setup is caused by Secure Boot. If this is enabled, the driver will be rejected.
I am trying to set up a CA and I need a root certificate for this CA. This root certificate has to be signed by a public CA and the signing algorithm has to be ECDSA with prime256v1 curve.
I am following this issue on LetsEncryp forum. However, I am using a separate utility for generating the keys and CSR. This utility helps me generate ECDSA keys and CSR successfully. Following is the CSR that's generated:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: O=MyOrg, L=Bengaluru, ST=Karnataka, C=IN, CN=mydomain.in
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
<value>
ASN1 OID: prime256v1
NIST CURVE: P-256
Attributes:
Requested Extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA256
<value>
So, basically I am getting correct values for KeyUsage and BasicConstraints in the extension.
Now, for the next step, I am using the following command from my ec2 instance:
certbot certonly -d <mydomain> --server https://acme-v02.api.letsencrypt.org/directory --csr <csr_generated_above> --cert-name <mydomain>
Using this command I'm able to get a certificate signed by LetsEncrypt along with the certificate chain. However, in the certificate that is generated, I get different values for KeyUsage and BasicConstraints:
Owner: CN=<my_domain>
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Serial number: <value>
Valid from: Fri Jan 03 14:46:29 UTC 2020 until: Thu Apr 02 14:46:29 UTC 2020
Certificate fingerprints:
SHA1: <value>
SHA256: <value>
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 256-bit EC key
Version: 3
Extensions:
#1: <value>
#2: <value>
#3: <value>
#4: ObjectId: <value> Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
#5: <value>
#6: ObjectId: <value> Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
#7: ObjectId: <value> Criticality=true
KeyUsage [
DigitalSignature
]
#8: <value>
#9: <value>
As seen above, the KeyUsage, BasicConstraints and Signature algorithm are not persisted. And the issue is my CA needs that one of the values of KeyUsage should be 'Certificate Sign'. Due to which my CA is not able to spinup.
So my question is:
Is it feasible to get a root cert for my CA from LetsEncrypt?
If yes, do we need to pass some extra flags with the cert bot command?
Or where am I getting this wrong?
I'm quite new to using public ca for the certificate generation.
LetsEncrypt does not issue anything except Domain Validated certificates. No code signing certificates, no root CA certificates, nothing else.
https://letsencrypt.org/docs/faq/
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.
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).
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