I'm having issues signing my electron mac app.
I'm trying to upload the pkg to MacStore, but I get rejected by them as the software appears to be done by an unknown developer.
I have my Developer Id Certificate and everything (I guess) is required.
After building and notarizing my app (I received the confirmation from Apple that the notarizing was successful I get the following information when running those commands:
codesign -dvv dist/mas/app-1.1.9.pkg
Executable=/Users/user/Documents/Development/app/electron-app/dist/mas/App-1.1.9.pkg
Identifier=MyCompany-1
Format=generic
CodeDirectory v=20200 size=172 flags=0x10000(runtime) hashes=1+2 location=embedded
Signature size=9059
Authority=Developer ID Application: MyCompany Inc (xxxxxxxx)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=23 Dec 2021 09:43:58
Info.plist=not bound
TeamIdentifier=xxxxxxx
Sealed Resources=none
Internal requirements count=1 size=172
spctl -vvv --assess --type exec dist/mas/electron-app-1.1.9.pkg
dist/mas/electron-app-1.1.9.pkg: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: MyCompany Inc (xxxxxx)
pkgutil --check-signature dist/mas/app-1.1.9.pkg
Package "app-1.1.9.pkg":
Status: signed by a developer certificate issued by Apple (Development)
Certificate Chain:
1. 3rd Party Mac Developer Installer: MyCompany Inc (xxxxxx)
Expires: 2022-12-06 02:39:58 +0000
------------------------------------------------------------------------
2. Apple Worldwide Developer Relations Certification Authority
Expires: 2030-02-20 00:00:00 +0000
------------------------------------------------------------------------
3. Apple Root CA
Expires: 2035-02-09 21:40:36 +0000
Any clue where the issue could be?
Related
While performing certificate verification the certutil.exe connects to different external resources.
The util freezes for 5-10 seconds on the step CERT_CHAIN_POLICY_BASE, on endentity and even Root certificates.
How it can be disabled and why does it happen?
I copied certutil.exe from another server where no such issue, compared hashes, launched but the same.
Command: certutil.exe -verify GlobalSign_root.cer
OS: Microsoft Windows Server 2016 Standard 10.0.14393 N/A Build 14393
External resources it connects:
a95-101-142-11.deploy.static.akamaitechnologies.com:http
map2.hwcdn.net:http
80-239-217-59.customer.teliacarrier.com:http
Others
Procmon64.exe.exe shows who connects: certutil.exe
Command output:
C:\Temp\certs>certutil -verify GlobalSign.cer
Issuer:
CN=GlobalSign
O=GlobalSign
OU=GlobalSign Root CA - R3
Name Hash(sha1): f59c687f2418d62a790f7592330756ea85e94707
Name Hash(md5): 01728e1ecf7a9d86fb3cec8948aba953
Subject:
CN=GlobalSign
O=GlobalSign
OU=GlobalSign Root CA - R3
Name Hash(sha1): f59c687f2418d62a790f7592330756ea85e94707
Name Hash(md5): 01728e1ecf7a9d86fb3cec8948aba953
Cert Serial Number: 04000000000121585308a2
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
NotBefore: 3/18/2009 3:00 AM
NotAfter: 3/18/2029 3:00 AM
Subject: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
Serial: 04000000000121585308a2
Cert: d69b561148f01c77c54578c10926df5b856976ad
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[2] = 1.3.6.1.5.5.7.3.3 Code Signing
Application[3] = 1.3.6.1.5.5.7.3.4 Secure Email
Application[4] = 1.3.6.1.5.5.7.3.8 Time Stamping
Application[5] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System
Application[6] = 1.3.6.1.5.5.7.3.6 IP security tunnel termination
Application[7] = 1.3.6.1.5.5.7.3.7 IP security user
Exclude leaf cert:
Chain: da39a3ee5e6b4b0d3255bfef95601890afd80709
Full chain:
Chain: d69b561148f01c77c54578c10926df5b856976ad
------------------------------------
Verified Issuance Policies: All
Verified Application Policies:
1.3.6.1.5.5.7.3.1 Server Authentication
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.3 Code Signing
1.3.6.1.5.5.7.3.4 Secure Email
1.3.6.1.5.5.7.3.8 Time Stamping
1.3.6.1.4.1.311.10.3.4 Encrypting File System
1.3.6.1.5.5.7.3.6 IP security tunnel termination
1.3.6.1.5.5.7.3.7 IP security user
Cert is a CA certificate
Cannot check leaf certificate revocation status
CertUtil: -verify command completed successfully.
C:\Temp\certs>
It got also pass for endentity certificate but still make external connection.
....
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully
If you disable network communication (so, for example, non-hostfile DNS can't be contacted), is the output different?
copied certutil.exe from another server where no such issue, compared hashes, launched but the same.
Can you clarify? You mean you copied an alternate version of certutil.exe from a different server and did not see the same behavior?
If so, there is a documented issue with certutil.exe in the exact build of Windows Server 2016 you're running, described here:
https://www.pkisolutions.com/certutil-bug-in-windows-server-2016-fails-to-enumerate-issuance-application-policies-and-oids/
In that case, the error was a failure to enumerate or verify certificate policies enforced by the issuing CA, but since the Microsoft recommendation is to:
copy the certutil (and the accompanying certutil.exe.mui) file from the System32 folder on either a Windows Server 2012 R2, Windows Server 2019 or Windows 10 machine. Place the files and the certificate file you’re wanting to check in a separate folder and run it from there.
...you might want to validate the behavior on other versions of Windows Server or with other versions of certutil.
I am using mitmproxy on two different machines. The versions are
Mitmproxy: 4.0.4
Python: 3.8.2
OpenSSL: OpenSSL 1.1.1f 31 Mar 2020
Platform: Linux-5.4.0-33-generic-x86_64-with-glibc2.29
and
Mitmproxy: 5.1.1
Python: 3.8.2
OpenSSL: OpenSSL 1.1.1g 21 Apr 2020
Platform: macOS-10.15.4-x86_64-i386-64bit
One thing, that really puzzles me: How come that the ca-certificates have the same hash value?
AFAIK, the key-pair of which the public one will go into the cert are created dynamically on installation or whenever someones deletes them in .mitmproxy.
But interestingly, both have the same hash value:
> openssl x509 -in .mitmproxy/mitmproxy-ca-cert.pem -noout -hash
8bbe0e8d
This applies actually to a few more installations i did in order to investigate this behaviour.
when I have a look at the modulus, all look different, so this seems to indicate that the keys are in fact different. But AFAIK the hash key is calculated over the key/modulus as well so I would like to know, why I find the same hash value 8bbe0e8d everywhere?
This leads to some interesting side effect:
E.g. on linux the root ca certs are usually in /etc/ssl/certs.
They are deployed there with a sensible name and in addition there is a a symlink pointing to that file.
The name of the symlink ist the hash-value of the cert followed by a sequence number. This is generated by the c_rehash tool of openssl. Normally there are no hash collisions and all sequence numbers are 0.
But in the case of a linux system containing ca-certs of two different mitmproxy-instances we have something like this
# ls -l /etc/ssl/certs/ | grep mitm
lrwxrwxrwx 1 root root 21 Jun 1 21:45 8bbe0e8d.0 -> mitmproxy-systema-ca-cert.pem
-rw-r--r-- 1 root root 1318 Jun 1 21:44 mitmproxy-systema-ca-cert.pem
lrwxrwxrwx 1 root root 21 Jun 1 22:34 8bbe0e8d.1 -> mitmproxy-systemb-ca-cert.pem
-rw-r--r-- 1 root root 1318 Jun 1 22:34 mitmproxy-systemb-ca-cert.pem
So to repeat my question:
Why is the hash value always 8bbe0e8d?
Is - contrary to my belief - the modulus not calculated into the hash
value?
are all mitmproxies using the same keys (which I hope they don´t)?
Any different reason?
Thanks in advance
Christian
Please find the relevant openssl output below:
>> openssl x509 -in mitmproxy-systema-ca-cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15904961119818 (0xe77298ec64a)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=mitmproxy, O=mitmproxy
Validity
Not Before: May 24 12:28:31 2020 GMT
Not After : May 26 12:28:31 2023 GMT
Subject: CN=mitmproxy, O=mitmproxy
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d3:60:2a:3a:8b:bc:9a:2c:fb:da:90:33:fa:a1:
a9:7a:96:52:e4:73:56:c8:c8:7f:8b:f8:ab:4b:e0:
55:2e:05:75:5b:55:4d:6d:58:b0:82:56:23:ac:ee:
ba:d4:4e:b0:ab:8e:52:25:2c:12:ef:fe:23:3b:f5:
0d:26:9e:cd:1e:d5:7c:5a:7b:e0:c6:6b:af:b6:b0:
cd:d1:5b:8b:12:ea:a1:d4:15:78:37:84:f2:d1:48:
61:7b:9b:c6:ec:e3:2c:41:32:72:15:15:d1:5f:7b:
87:01:40:86:6a:cf:5f:2a:0f:19:71:c5:37:08:94:
8c:4d:18:af:5d:5d:80:89:46:e9:04:23:f4:e7:84:
4e:97:ee:81:91:07:c8:18:5e:eb:64:3a:47:9e:c1:
29:50:2c:27:c7:80:35:b9:d6:ec:61:91:de:23:af:
04:7d:0c:e8:43:32:52:09:c9:34:ba:fd:98:51:ef:
78:13:2c:83:4a:e9:31:6e:d8:53:6b:12:79:44:e9:
5b:70:7a:b5:79:2e:00:a9:9f:53:f3:2f:c6:75:b0:
90:1b:00:b4:50:21:5e:fe:b5:a3:36:18:c5:42:cd:
fc:d5:33:e4:1b:c1:26:12:04:05:95:e5:99:7c:23:
2a:ea:de:f3:45:7e:3b:9d:e9:56:a5:83:07:61:e9:
dd:19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Netscape Cert Type:
SSL CA
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, E-mail Protection, Time Stamping, Microsoft Individual Code Signing, Microsoft Commercial Code Signing, Microsoft Trust List Signing, Microsoft Server Gated Crypto, Microsoft Encrypted File System, Netscape Server Gated Crypto
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
03:9C:EC:D3:BD:2A:C4:A8:E8:23:04:F2:AD:69:C9:2E:CF:CE:85:85
Signature Algorithm: sha256WithRSAEncryption
6d:98:36:7e:e6:2f:54:7d:7f:0a:9b:85:d5:ef:e6:c3:c7:df:
c8:c4:1b:3e:78:51:ee:48:8c:c2:0c:ac:8f:89:67:06:22:3f:
fe:05:f4:17:2b:1c:23:0e:53:1f:0e:7b:23:e1:fe:ac:9c:52:
ac:13:11:06:be:00:55:13:36:1a:47:22:29:41:79:f8:ca:8e:
2b:5a:26:57:b6:26:80:da:7d:ac:10:5f:53:b9:00:e4:d9:ed:
51:04:52:af:d0:7c:33:ce:24:6f:eb:06:d0:49:c6:da:71:25:
64:fe:66:0b:29:90:99:7f:b7:c4:3d:f9:17:5b:24:21:ae:7c:
3f:b1:33:b5:af:64:e2:bc:44:d4:41:df:35:ca:45:8a:08:61:
7a:76:8b:4c:7c:23:80:1d:87:97:29:98:78:a3:38:bf:3c:8d:
5c:79:43:64:95:77:4d:50:cb:a2:17:fd:cf:f9:9f:42:b4:d5:
20:8a:2c:12:af:9d:cd:34:b4:be:53:ad:e4:d8:33:bb:fe:7d:
a1:57:e6:cf:b7:a6:30:a2:3d:f6:8f:4d:4b:f6:2b:cc:19:df:
d2:d5:6e:25:d2:92:13:db:60:f9:6c:e4:bc:09:56:07:5a:30:
6f:89:67:1a:e4:93:52:bd:f6:89:ab:1f:71:17:6b:78:97:69:
05:46:a6:2f
-----BEGIN CERTIFICATE-----
MIIDoTCCAomgAwIBAgIGDncpjsZKMA0GCSqGSIb3DQEBCwUAMCgxEjAQBgNVBAMM
CW1pdG1wcm94eTESMBAGA1UECgwJbWl0bXByb3h5MB4XDTIwMDUyNDEyMjgzMVoX
DTIzMDUyNjEyMjgzMVowKDESMBAGA1UEAwwJbWl0bXByb3h5MRIwEAYDVQQKDAlt
aXRtcHJveHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTYCo6i7ya
LPvakDP6oal6llLkc1bIyH+L+KtL4FUuBXVbVU1tWLCCViOs7rrUTrCrjlIlLBLv
/iM79Q0mns0e1Xxae+DGa6+2sM3RW4sS6qHUFXg3hPLRSGF7m8bs4yxBMnIVFdFf
e4cBQIZqz18qDxlxxTcIlIxNGK9dXYCJRukEI/TnhE6X7oGRB8gYXutkOkeewSlQ
LCfHgDW51uxhkd4jrwR9DOhDMlIJyTS6/ZhR73gTLINK6TFu2FNrEnlE6VtwerV5
LgCpn1PzL8Z1sJAbALRQIV7+taM2GMVCzfzVM+QbwSYSBAWV5Zl8Iyrq3vNFfjud
6Valgwdh6d0ZAgMBAAGjgdAwgc0wDwYDVR0TAQH/BAUwAwEB/zARBglghkgBhvhC
AQEEBAMCAgQweAYDVR0lBHEwbwYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcD
BAYIKwYBBQUHAwgGCisGAQQBgjcCARUGCisGAQQBgjcCARYGCisGAQQBgjcKAwEG
CisGAQQBgjcKAwMGCisGAQQBgjcKAwQGCWCGSAGG+EIEATAOBgNVHQ8BAf8EBAMC
AQYwHQYDVR0OBBYEFAOc7NO9KsSo6CME8q1pyS7PzoWFMA0GCSqGSIb3DQEBCwUA
A4IBAQBtmDZ+5i9UfX8Km4XV7+bDx9/IxBs+eFHuSIzCDKyPiWcGIj/+BfQXKxwj
DlMfDnsj4f6snFKsExEGvgBVEzYaRyIpQXn4yo4rWiZXtiaA2n2sEF9TuQDk2e1R
BFKv0HwzziRv6wbQScbacSVk/mYLKZCZf7fEPfkXWyQhrnw/sTO1r2TivETUQd81
ykWKCGF6dotMfCOAHYeXKZh4ozi/PI1ceUNklXdNUMuiF/3P+Z9CtNUgiiwSr53N
NLS+U63k2DO7/n2hV+bPt6Ywoj32j01L9ivMGd/S1W4l0pIT22D5bOS8CVYHWjBv
iWca5JNSvfaJqx9xF2t4l2kFRqYv
-----END CERTIFICATE-----
>> openssl x509 -in mitmproxy-systemb-ca-cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15891076851956 (0xe73edfda8f4)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=mitmproxy, O=mitmproxy
Validity
Not Before: May 8 10:48:05 2020 GMT
Not After : May 10 10:48:05 2023 GMT
Subject: CN=mitmproxy, O=mitmproxy
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d4:27:ef:99:12:9b:84:9d:82:a7:d1:96:e6:fe:
14:cf:a5:1a:d5:95:f5:1f:b3:25:fc:10:df:1a:f1:
20:4a:a5:e9:e9:b9:20:ba:d3:c2:88:e9:cb:fe:66:
43:5e:4a:1d:9c:39:f4:a8:64:50:51:f6:18:0b:f2:
a2:b3:da:1d:a5:0d:01:c5:bd:c0:6c:b7:a7:25:cd:
6d:d7:21:2b:ba:a8:35:b6:a4:a3:33:0d:15:8d:44:
8e:bb:70:d6:1a:9b:c2:21:09:f9:70:fc:42:8c:d6:
a9:1b:d2:d1:0c:4b:03:f2:44:ca:c7:bf:8f:8b:e2:
fe:0c:ff:99:fe:61:f2:8f:6e:26:ae:ec:60:6c:ff:
ec:51:db:3e:3c:3e:a9:32:38:61:13:52:8e:40:15:
b0:8d:f7:7b:b8:d9:11:84:d6:dc:bd:9e:12:58:5c:
03:13:d6:73:6e:95:84:5f:8d:21:72:bb:17:27:a7:
19:b4:00:43:7b:bc:2e:f2:d9:8a:68:53:0d:de:bc:
03:6c:f8:78:c9:e6:43:1f:45:1e:b0:d0:7d:3b:a7:
cc:05:f2:cb:b1:5f:9c:5f:7f:ee:f3:4e:94:99:28:
33:6f:65:eb:24:a2:44:f1:22:13:a7:71:cd:88:15:
c3:14:77:a2:3c:dc:59:6c:10:81:0f:f1:89:ef:90:
1d:b5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Netscape Cert Type:
SSL CA
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, E-mail Protection, Time Stamping, Microsoft Individual Code Signing, Microsoft Commercial Code Signing, Microsoft Trust List Signing, Microsoft Server Gated Crypto, Microsoft Encrypted File System, Netscape Server Gated Crypto
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
FE:50:10:81:42:BA:C2:85:01:CB:D2:B4:2E:FF:F1:B3:CD:B2:63:16
Signature Algorithm: sha256WithRSAEncryption
00:d0:fe:58:df:07:90:b9:03:25:b9:0c:6d:37:e4:65:aa:0f:
f9:d4:ea:9a:42:b7:3e:0f:8f:d3:1e:c4:26:03:ff:57:5b:6f:
3d:36:fb:cd:61:4f:4a:5a:20:71:5e:96:25:b3:d2:31:4b:da:
ec:6c:6e:30:e9:0f:77:5b:fe:34:95:5d:31:2a:bf:53:b9:f4:
94:98:5c:fa:b9:c5:27:1a:7e:51:2e:dd:75:f5:c6:51:f7:8d:
69:66:77:9c:e6:0f:7c:79:1a:2f:ca:be:16:9e:45:3f:4b:ff:
49:d8:5d:37:5f:d5:2c:f4:cd:bd:06:fd:09:b0:7b:4b:2b:21:
99:40:24:0a:f6:5f:c3:9c:2f:58:f6:60:b6:b4:3c:b6:89:43:
a6:be:a0:4a:9b:d4:2d:06:b3:2c:b3:eb:c6:18:5a:e4:b1:2b:
f7:b3:7a:a6:41:96:1e:09:19:39:37:25:e0:2c:7a:31:aa:bf:
f8:1a:c2:76:9b:32:30:b7:20:28:ea:63:a9:f7:16:ba:4d:23:
a5:90:7c:0f:31:b9:cd:f8:77:64:8f:28:5f:b8:10:64:4d:08:
f8:6a:9c:45:6f:c7:28:2e:4c:2c:34:09:ef:57:ed:c6:0e:c3:
6d:db:a4:de:8c:72:30:2d:59:8d:c1:e1:2c:6d:29:89:d5:9d:
86:c3:fb:65
-----BEGIN CERTIFICATE-----
MIIDoTCCAomgAwIBAgIGDnPt/aj0MA0GCSqGSIb3DQEBCwUAMCgxEjAQBgNVBAMM
CW1pdG1wcm94eTESMBAGA1UECgwJbWl0bXByb3h5MB4XDTIwMDUwODEwNDgwNVoX
DTIzMDUxMDEwNDgwNVowKDESMBAGA1UEAwwJbWl0bXByb3h5MRIwEAYDVQQKDAlt
aXRtcHJveHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUJ++ZEpuE
nYKn0Zbm/hTPpRrVlfUfsyX8EN8a8SBKpenpuSC608KI6cv+ZkNeSh2cOfSoZFBR
9hgL8qKz2h2lDQHFvcBst6clzW3XISu6qDW2pKMzDRWNRI67cNYam8IhCflw/EKM
1qkb0tEMSwPyRMrHv4+L4v4M/5n+YfKPbiau7GBs/+xR2z48PqkyOGETUo5AFbCN
93u42RGE1ty9nhJYXAMT1nNulYRfjSFyuxcnpxm0AEN7vC7y2YpoUw3evANs+HjJ
5kMfRR6w0H07p8wF8suxX5xff+7zTpSZKDNvZeskokTxIhOncc2IFcMUd6I83Fls
EIEP8YnvkB21AgMBAAGjgdAwgc0wDwYDVR0TAQH/BAUwAwEB/zARBglghkgBhvhC
AQEEBAMCAgQweAYDVR0lBHEwbwYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcD
BAYIKwYBBQUHAwgGCisGAQQBgjcCARUGCisGAQQBgjcCARYGCisGAQQBgjcKAwEG
CisGAQQBgjcKAwMGCisGAQQBgjcKAwQGCWCGSAGG+EIEATAOBgNVHQ8BAf8EBAMC
AQYwHQYDVR0OBBYEFP5QEIFCusKFAcvStC7/8bPNsmMWMA0GCSqGSIb3DQEBCwUA
A4IBAQAA0P5Y3weQuQMluQxtN+Rlqg/51OqaQrc+D4/THsQmA/9XW289NvvNYU9K
WiBxXpYls9IxS9rsbG4w6Q93W/40lV0xKr9TufSUmFz6ucUnGn5RLt119cZR941p
Znec5g98eRovyr4WnkU/S/9J2F03X9Us9M29Bv0JsHtLKyGZQCQK9l/DnC9Y9mC2
tDy2iUOmvqBKm9QtBrMss+vGGFrksSv3s3qmQZYeCRk5NyXgLHoxqr/4GsJ2mzIw
tyAo6mOp9xa6TSOlkHwPMbnN+HdkjyhfuBBkTQj4apxFb8coLkwsNAnvV+3GDsNt
26TejHIwLVmNweEsbSmJ1Z2Gw/tl
-----END CERTIFICATE-----
For example on a freshly installed ubuntu 20.04 box or a fresh container,
issueing the following commands reproduces the issue not only for me:
apt update
apt install mitmproxy
mitmdump
<CTRL-C>
openssl x509 -in /root/.mitmproxy/mitmproxy-ca-cert.pem -hash -issuer_hash
8bbe0e8d
8bbe0e8d
Of course both hashes are the same, it is a self-signed root cert. But I find it surprising that I always get the hash value of 8bbe0e8d. Everywhere.
The answer to solve this riddle is documented in the OpenSSL man page:
-issuer_hash
outputs the "hash" of the certificate issuer name.
And as you can see in the output of your certificate the issuer of the certificate is fixed and therefore the same on each and every system mitmproxy is installed: CN=mitmproxy, O=mitmproxy
A fixed input always outputs the same hash value of course.
One Root CA certificate can have multiple child certificates. Hence all those child certificates have the same issuer and therefore are all mapped to the same hash. Therefore it is nothing unusual that multiple certificates in /etc/ssl/certs/ are mapped to the same hash value. This seems to be some sort of grouping.
Using at that point the certificate fingerprint (or the issuer certificate fingerprint) does not make much sense, because when you use /etc/ssl/certs/ usually you want to find exactly the data of this certificate. If you would already know the certificate fingerprint you also have the certificate and hence doe not have to search for the certificate data.
I'm trying to debug an issue in kerberos configuration. I generated a service ticket using the kgetcred utility. I'd like to access the value of the service ticket so that I can put it into the Authorization header of a request to the protected resource.
I ran the following:
kinit myUser
kgetcred HTTP/myProtectedResource#MY.DOMAIN.COM
I can see the ticket exists by running
$klist
Credentials cache: FILE:/tmp/krb5cc_1000
Principal: myUser#MY.DOMAIN.COM
Issued Expires Principal
Jan 30 15:37:39 2017 Jan 31 01:37:39 2017 krbtgt/MY.DOMAIN.COM#MY.DOMAIN.COM
Jan 30 16:02:39 2017 Jan 31 01:37:39 2017 HTTP/myProtectedResource#MY.DOMAIN.COM
I had a look inside the /tmp/krb5cc_1000 file, but this seems encrypted of encoded somehow.
How can I get the value of this ticket to put in the Authorization header when making an HTTP request to the protected resource?
Am following these tutorials to enable Apple Push Notification Server to send Notifications to device.
http://www.raywenderlich.com/3525/apple-push-notification-services-tutorial-part-2
From this tutorial I downloaded MAMP and "created the database to store the users details" and also I have "downloaded the PushChatServer folder from the tutorial". I stored the UDID, Device Token (from APNS), Name, Code in the database. Now I want to send Push Notifications from my localhost.
I am keeping the .pem file, push.php, push-confi.php on my desktop. From the tutorial this part I don't understand:
In the PushChatServer directory there is a push folder that contains the PHP scripts you need to send out push requests. You should put these files in a directory on the server that is not accessible from the web, in other words outside of your DocumentRoot. This is important because you don’t want visitors to your website to download your private key! (In our MAMP setup, this is already taken care of.)
The most important script in the push folder is push.php. This script should be run as a background process on your server. Every few seconds it checks if there are new push notifications to be sent out. If so, it sends them to the Apple Push Notification Service.
First, we need to edit the file push_config.php, which contains the configuration options for push.php. You may need to change the passphrase for the private key and possibly the database password.
As with the server API, the push script can run in either development mode or production mode. In development mode, it talks to the APNS sandbox server and it uses your development SSL certificate. You should use development mode in combination with Debug builds of your app. Production mode should be used for Ad Hoc and App Store builds of your app.
Where I want to keep my Push folder in my Mac. How can I check the APNS connection?
I placed the Push folder(Which is contains the Push.php) in my directory to read from Terminal. And also I pasted the Application folder in my directory.
Tutorial said to use this command in Terminal
$ /Applications/MAMP/bin/php5.2/bin/php push.php development
But, in MAMP I have this path
/Users/creagx/Applications/MAMP/bin/php/php5.5.17/bin/php
Where I need to place the Push folder and MAMP.
I kept my .pem files and push.php files in this path: /Users/gopi/Desktop/APNSsample/push.php
Then I have tried to connect my .pem (SSL) to APNS using Terminal app like this
unknownc42c032e8297:~ name$ cd /Users/creagx/Desktop/APNSsample
unknownc42c032e8297:APNSsample name$ telnet gateway.sandbox.push.apple.com 2195
Trying 17.149.34.66...
Connected to gateway.sandbox.push-apple.com.akadns.net.
Escape character is '^]'.
^C
Connection closed by foreign host.
unknownc42c032e8297:APNSsample name$ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert NameAPNCert.pem -key NameAPNKey.pem
Enter pass phrase for NameAPNKey.pem:
CONNECTED(00000003)
depth=1 /C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Cupertino/O=Apple Inc/OU=Internet Services/CN=gateway.sandbox.push.apple.com
i:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
1 s:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
i:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEZTCCA02gAwIBAgIESyDhfjANBgkqhkiG9w0BAQUFADCBsTELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9ycGEgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
KGMpIDIwMDkgRW50cnVzdCwgSW5jLjEuMCwGA1UEAxMlRW50cnVzdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSAtIEwxQzAeFw0xMDA0MTMyMzM0MzNaFw0xMjA1MzEw
MDA0MjdaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAG
A1UEBxMJQ3VwZXJ0aW5vMRIwEAYDVQQKEwlBcHBsZSBJbmMxGjAYBgNVBAsTEUlu
dGVybmV0IFNlcnZpY2VzMScwJQYDVQQDEx5nYXRld2F5LnNhbmRib3gucHVzaC5h
cHBsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM5NngiDMFpGBMmb
8tG2MRhLEdsx553Xjq+5C/c0mtildwhnC1X0LWKUexWdQsMchniac+WnHFSs3YMJ
JJ55kQSB6wqK/WNcxsUn8pMkMsvk3YZFM7TsaKQvFOeieiXCSJVlR3grm3+dilv1
Br+SUqv8JrgU3ijmoQO63vkb8B/hAgMBAAGjggEnMIIBIzALBgNVHQ8EBAMCBaAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvbGV2ZWwxYy5jcmwwMwYIKwYBBQUHAQEE
JzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5lbnRydXN0Lm5ldDBABgNVHSAE
OTA3MDUGCSqGSIb2fQdLAjAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1
c3QubmV0L3JwYTAfBgNVHSMEGDAWgBQe8auJBvhJDwEzd+4Ueu4ZfJMoTTAdBgNV
HQ4EFgQUNyg/64Sjw/+b4YOwC8E/c+jemRgwCQYDVR0TBAIwADANBgkqhkiG9w0B
AQUFAAOCAQEAk9Ij+NCp+323+4vBqbA0fT9ZCROptPqNIshY5uEvaWUaW5hsoLUm
fsMJMueqzDaoj4yPD8iCCZq1Mp8tM8WB2mG1zIxTLshlhRgDDUF11IbUUBHv/ZhU
RzXewQD6pazQmsBPuR0vP3mmWbKqmZOiv2yWSGlQmWGW4m6RQwjYYj8UqqFEdinV
g1+qY6/muTpaCiygDjJZBlv9P6bwwP9FB8OJf5tGECvvxXad3PK/oiI77aLTYSVr
SA0oisXCiqcgTKQq5BV5M3fQQ4ZS73aBKLI0wPYc0AASD5WdtPTGTvmEbhO4KeaU
0SL85Prf8uSsDOLvn3656awLz/H/yzrf/g==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc/OU=Internet Services/CN=gateway.sandbox.push.apple.com
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
No client certificate CA names sent
---
SSL handshake has read 2549 bytes and written 2017 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: 729CC0899B36143DAC78D40B2C31ECB71C81A3BD8DC5CFD6D71AC7885DD2E63DCD47096E97A1B3AF032A8D7D48BF73DA
Key-Arg : None
Start Time: 1336636910
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
name
closed
unknownc42c032e8297:APNSsample name$ php push.php
Usage: php push.php development|production
unknownc42c032e8297:APNSsample name$ development
-bash: development: command not found
unknownc42c032e8297:APNSsample name$ php push.php development
I have received the APNS connection status in push_development.log like this,
2012-05-10T13:32:34+05:30 Push script started (development mode)
2012-05-10T13:32:34+05:30 Exiting with fatal error: exception 'PDOException' with message 'SQLSTATE[HY000] [2002] No such file or directory' in /Users/name/Desktop/APNSsample/push.php:82
Stack trace:
#0 /Users/creagx/name/APNSsample/push.php(82): PDO->__construct('mysql:host=loca...', 'pushchat', 'name', Array)
#1 /Users/creagx/name/APNSsample/push.php(36): APNS_Push->__construct(Array)
#2 {main}
I can't understand what I did wrong? I am using the database from MAMP. I have stored the devicetoken, messages (Payload) in MAMP SQL database.
Terminal:
unknownc42c032e8297:~ gopi$ cd /Users/gopi/Desktop/APNSsample/
unknownc42c032e8297:APNSsample gopi$ php push.php
Usage: php push.php development|production
unknownc42c032e8297:APNSsample gopi$ php push.php development
unknownc42c032e8297:APNSsample gopi$
In my push_development.log file:
2012-05-10T16:08:12+05:30 Push script started (development mode)
2012-05-10T16:08:12+05:30 Exiting with fatal error: exception 'PDOException' with message 'SQLSTATE[HY000] [2002] No such file or directory' in /Users/gopi/Desktop/APNSsample/push.php:82
Stack trace:
#0 /Users/gopi/Desktop/APNSsample/push.php(82): PDO->__construct('mysql:host=loca...', 'pushchat', 'gopi', Array)
#1 /Users/gopi/Desktop/APNSsample/push.php(36): APNS_Push->__construct(Array)
#2 {main}
After you copy both of the .pem files to the same directory(in case desktop).Paste the following codes in terminal:
' cd /Users/gopi/Desktop/APNSSample/ '
Hit enter and you should get no erros,just a new line in Terminal.Now to test the connexion,paste the following code in terminal after you pasted the other one:
' php yourphpfile.php '
Hit enter and you should get three lines of code seying that the php file were able to reach the APNS Server.If it works,you're ok,else tell me!
We have a wildcard SSL certificate for our domains. If I setup the Secure Canvas URL, we get the dreaded empty response error. My understanding is that this is because Facebook has a problem with our SSL cert.
Is there any recommendations on how to figure out what is wrong with our SSL certificate?
I read this blog post: http://developers.facebook.com/blog/post/567/
I ran the test on the site they recommended, it looks pretty good to me. Could that Beast mode warning be causing this problem? Here are the results I get back:
Certificate Information
Common names *.mydomain.com
Alternative names *.mydomain.com mydomain.com
Prefix handling Not required for subdomains
Valid from Tue Jul 19 00:00:00 UTC 2011
Valid until Wed Jul 18 23:59:59 UTC 2012 (expires in 8 months and 18 days)
Key RSA / 2048 bits
Signature algorithm SHA1withRSA
Server Gated Cryptography Netscape Step-Up, Microsoft Server Gated Cryptography
Weak key (Debian) No
Issuer EssentialSSL CA
Next Issuer COMODO Certification Authority TRUSTED
Chain length (size) 2 (2581 bytes)
Chain issues None
Validation type Domain-validated (DV)
Revocation information CRL, OCSP
Revocation status Good (not revoked)
Trusted Yes
Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 Yes
SSL 2.0+ upgrade support Yes
SSL 2.0 Yes N
(*) N next to protocol version means the protocol has no cipher suites enabled
Cipher Suites (sorted by strength; server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) 168
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) 256
Miscellaneous
Test date Thu Nov 03 19:37:27 UTC 2011
Test duration 55.590 seconds
Server signature Apache
Server hostname dev.mydomain.com
Session resumption Yes
BEAST attack Vulnerable INSECURE (more info)
Secure Renegotiation Supported, with client-initiated renegotiation disabled
Insecure Renegotiation Not supported
Strict Transport Security No
TLS version tolerance 0x0304: 0x301; 0x0399: 0x301; 0x0499: fail
PCI compliant No
FIPS-ready No
Ephemeral DH 1024 bits (p: 128, g: 1, Ys: 128)
Are you missing the intermediate certificates? Check at http://www.sslshopper.com/ssl-checker.html to see if you have a full chain
Also good is the checker at https://www.ssllabs.com/
If the app is FBML Facebook is very strict about which certificates it will accept when connecting to your site to download the content - if your app uses iFrames it's mostly up to the user's browser settings and you'll get away with less strict checking
The quote from that blog post which seems to have tripped up most FBML apps is:
If you enable SSL for your FBML app, please make sure that your SSL certificate includes all intermediate certificates in the chain of trust as our SSL validation is strict. You can use third-party SSL analysis tools (e.g., https://www.ssllabs.com/index.html) to check your certificate status and fix any errors (and warnings). If your SSL certificate has problems, you may see "Empty response received" error when you load your FBML canvas app.