I am a home user working on Windows 7 X64. I have a problem with my signed APK.
My app is only for home use and learning. I won't submit to Google Play.
When installed, it shows
Blocked by Play Protect.
Play Protect doesn't recognise this app's developer.
Apps from unknown developers can sometimes be unsafe.
Tools:
keytool.exe v8.0.3019.9
openssl.exe v1.1.1k
zipalign.exe v29.0.3
apksigner.jar v29.0.3
Batch Script:
cls
del /f KEY.JKS
del /f KEY.PEM
del /f KEY.PK8
del /f CERT.PEM
"C:\Program Files\Java\jre1.8.0_301\bin\keytool.exe" -genkeypair -v -alias MYKEY -storepass 123456 -keypass 123456 -keystore KEY.JKS -keyalg RSA -keysize 2048 -validity 9999 -dname "EMAILADDRESS=android#android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US"
openssl.exe req -x509 -nodes -days 9999 -newkey rsa:2048 -keyout KEY.PEM -out CERT.PEM -subj "/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android#android.com" -config openssl.cnf
openssl.exe pkcs8 -topk8 -nocrypt -inform PEM -outform DER -in KEY.PEM -out KEY.PK8
zipalign.exe -f -p 4 myApp.apk myApp_Align.apk
rem java -jar apksigner.jar sign --ks KEY.JKS --ks-pass pass:123456 --out myApp_Signed.apk myApp_Align.apk
java -jar apksigner.jar sign --key KEY.PK8 --cert CERT.PEM --out myApp_Signed.apk myApp_Align.apk
java -jar apksigner.jar verify -v --print-certs myApp_Signed.apk
pause
My key got blocked:
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=android#android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: 07d51277869be18dfe8618d797ad1c0c8e16b7c067d9d224962af960c0382bfb
Signer #1 certificate SHA-1 digest: 85789690f7f12d0d6f4c7f67adb96429c326049f
Signer #1 certificate MD5 digest: 13b9633388142f4d40295cd45ac65aa9
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: bb280251b6eb2a1dd5e2493a3ac23881e254274318a2247bce84fd067181c441
Signer #1 public key SHA-1 digest: b2be0f31d13ce91162bf7ccf9fa4662e7c47b2d6
Signer #1 public key MD5 digest: 9648bca600a81a383cffd490a8614852
I downloaded some APK from the internet and it doesn't get blocked.
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=android#android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: a40da80a59d170caa950cf15c18c454d47a39b26989d8b640ecd745ba71bf5dc
Signer #1 certificate SHA-1 digest: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
Signer #1 certificate MD5 digest: e89b158e4bcf988ebd09eb83f5378e87
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: ef57b690165cb561b5026922c00d2d6574e8b184fa7d161e076f06e06e6d35db
Signer #1 public key SHA-1 digest: 0c2440c055c753a8f0493b4e602d3ea0096b1023
Signer #1 public key MD5 digest: 452f8cfe026b30a8a3e99a6074e5f285
I downloaded KEY.PK8 and CERT.PEM from the internet and it doesn't get blocked.
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=lorenz#londatiga.net, CN=Lorensius W. L. T, OU=AndroidDev, O=Londatiga, L=Bandung, ST=Jawa Barat, C=ID
Signer #1 certificate SHA-256 digest: 518ac8bdaf0c767deb31bae1eba826adbef793a68f22784cf3e19c67ba87ecb9
Signer #1 certificate SHA-1 digest: ece521e38c5e9cbea53503eaef1a6ddd204583fa
Signer #1 certificate MD5 digest: eea6f6f40858b8215c48b0465fe479b8
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 1024
Signer #1 public key SHA-256 digest: d8dc2ef9b37fcb543b07678a2d64d3a1dc5122642ee824a61dfbed0bf86d25c4
Signer #1 public key SHA-1 digest: 74bd7b456d9e651fc84446f65041bef1207c408d
Signer #1 public key MD5 digest: 58d291bc49e568eb8fc84dabaf508d08
What's wrong with my steps? I switched to keystore (KEY.JKS), it didn't work too.
Unless google knows your key's fingerprint or the APK itself is signed with a google key, it gets flagged by play protect as "unknown developer". You can "verify" your key by submitting an application signed by that particular key on google play
Related
I have two extremely similar self signed certificates, generated via two different methods.
To test them I have:
Added an entry in my hosts file for local.mydomain.com
Set up an nginx server to listen on that domain on port 443 with the certificate under test plus associated private key (I then switch the cert and restart nginx to compare)
Connected to nginx with openssl s_client -connect local.mydomain.com -CAfile /path/to/the/ca/cert.pem
One certificate fails:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = local.mydomain.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=local.mydomain.com
i:/CN=local.mydomain.com
---
One certificate succeeds:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify return:1
---
Certificate chain
0 s:/CN = local.mydomain.com
i:/CN = local.mydomain.com
---
I compare the details of the certificates with openssl x509 -in /path/to/the/ca/cert.pem -text -noout
The failing cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
47:dc:02:c7:11:fc:8e:96:45:22:aa:6b:23:79:32:ca
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 18 11:55:31 2016 GMT
Not After : Nov 18 12:15:31 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:local.mydomain.com
X509v3 Subject Key Identifier:
6D:4F:AF:E4:60:23:72:E5:83:27:91:7D:1D:5F:E9:7C:D9:B6:00:2A
Signature Algorithm: sha256WithRSAEncryption
<stuff>
The working cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9b:6b:3d:a3:b9:a3:a4:b4
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 19 13:27:30 2016 GMT
Not After : Nov 19 13:27:30 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Authority Key Identifier:
keyid:03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
57<stuff>
Looking at this the most obvious difference is that the working cert has CA:TRUE under X509v3 Basic Constraints. However, from reading around the web I was under the impression that self signed certs weren't meant to be CAs, in particular this says they normally won't be:
https://security.stackexchange.com/questions/44340/basic-self-signed-certificate-questions
The answer there says that being self-signed there is no CA involved. But maybe openssl requires self signed certs to have that set anyway?
From my own experiments I can confirm what you see. My explanation of the behavior is that a self signed certificate is still a certificate which is signed by the issuer, even if the issuer's certificate is the certificate itself. But only CA certificates can be used to sign certificates, i.e. that's exactly the constraint CA:true allows. This means that a self-signed certificate needs also to be a CA certificate with the constraint CA:true.
RFC5280 says:
So, if your certificate does not have CA:TRUE flag, this certificate may not be used to verify the signature on any certificate, including itself. OpenSSL correctly follows the RFC.
It is incorrect to think that a certificate belongs to one of two types, either "CA certificate" or "end-entity certificate". A certificate with CA:TRUE can be used for authenticating the entity. This is exactly what you do when you authenticate with a self-signed certificate. It can also be a certificate with CA:TRUE, signed by someone else.
Starting with an empty directory:
Generate CAroot private key
$ openssl genrsa -aes256 -out dcsAzureVPN.key 2048
Generate a CARoot certificate
$ openssl req -x509 -sha256 -new -key dcsAzureVPN.key -out dcsAzureVPN.cer -days 1825 -subj /CN="dcsAzureVPN"`
Successfully copied dcsAzureVPN.cer to VPN gateway and saved (see attached screenshot)
Generate Certificate Request (CSR)
$ openssl genrsa -out dcsAzureClientCert.key 2048
$ openssl req -new -out tjaClientCert.req -key dcsAzureClientCert.key -subj /CN="dcsAzureVPN"`
Generate signed Client Certificate from CSR
$ openssl x509 -req -sha256 -in tjaClientCert.req -out dcsAzureClientCert.cer -CAkey dcsAzureVPN.key -CA dcsAzureVPN.cer -days 1825 -CAcreateserial -CAserial serial
Signature ok
subject=/CN=dcsAzureVPN
Pack key and certificate in .pfx format
$ openssl pkcs12 -export -out dcsAzureVPNClient.pfx -inkey dcsAzureClientCert.key -in dcsAzureClientCert.cer -certfile dcsAzureVPN.cer
Copy client cert to my Keychain
Make dcsAzure VPN a trusted cert.
Select dcsAzureVPN as the client certificate for my VPN connection
Try to connect. Connection fails with an error: User Authentication failed
What am I doing wrong?
I finally found the problem. It turns out the Local ID has to match the client certificate subject, not the name of your client certificate file.
You have to manually configure the native IKEv2 VPN client on every Mac that will connect to Azure. You could use these steps to configure the native VPN client on Mac for certificate authentication.
Moreover, you could refer to this to troubleshoot Point-to-Site VPN connections from Mac OS X VPN clients.
Additionally, no matter what client OS you want to connect from, you must always have a client certificate. You can generate a client certificate from either a root certificate that was generated using an Enterprise CA solution or a self-signed root certificate. See the PowerShell, MakeCert, or Linux instructions for steps to generate a client certificate.
Please let me know if this works.
Whoever stumbles up on this solution: It is working if you change the Client certificate's subj from dcsAzureVPN to (for example) dcsAzureVPNSubj and use it in the connection tab for Local ID.
So instead of this:
openssl req -new -out tjaClientCert.req -key dcsAzureClientCert.key -subj /CN="dcsAzureVPN"
Use this:
openssl req -new -out tjaClientCert.req -key dcsAzureClientCert.key -subj /CN="dcsAzureVPNSubj"
and use the dcsAzureVPNSubj for Local id on the MacOS VPN connection tab.
Worked on the following machine:
20.5.0 Darwin Kernel Version 20.5.0: root:«gibberish»/RELEASE_ARM64_T8101 arm64
Big Sur version: 11.4
I created a self-signed certificate using these commands
sudo keytool -genkeypair -alias <MyAlias> -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore <MyCert>.p12 -validity 3650
sudo keytool -genkeypair -alias <MyAlias> -keyalg RSA -keysize 2048 -keystore <MyCert>.jks -validity 3650
sudo keytool -importkeystore -srckeystore <MyCert>.jks -destkeystore <MyCert>.p12 -deststoretype pkcs12
which created a P12 file and a jks file.
If I log in to my server remotely, the connection is blocked and an error is shown that indicates your connection is not private, because the certificate is not trusted.
How can I fix this issue?
Maybe I should chain the certificate to another certificate? (example: using Let's Encrypt)?
Create a Certificate Authority
You can create a Certificate Authority certificate and then sign a certificate with your own CA and then add your CA to the system keychain.
More on that at https://gist.github.com/Soarez/9688998
Use a Let's Encrypt client
... however, it's probably much easier to use a Let's Encrypt client.
I'm the author so you can take my opinion for a grain of salt, but Greenlock is about the easiest suite of Let's Encrypt / ACME tools available.
Browser-based client
https://greenlock.domains
If you use the DNS challenge you can easily get certs for private domains with internal IP addresses as well.
CLI Clients
If you want it automatic you could use something like Greenlock CLI or Greenlock Express (for node.js)
There's also certbot, but it can be more difficult to install due to it's size, various dependencies, and RAM usage. Greenlock is only about 100kb and has no external dependencies, so it works fine on home servers and memory constrained IoT devices (which is exactly the problem I had when I first wrote it).
I am trying to generate a chain (self signed + one signed by the self signed) of certificates using Ansible OpenSSL modules.
So far have the following tasks:
- name: Generate a Self Signed OpenSSL certificate
become: yes
block:
- apt:
name: python-openssl
update_cache: yes
- openssl_privatekey:
path: /tmp/ansible.com.pem
- openssl_csr:
path: /tmp/ansible.com.csr
privatekey_path: /tmp/ansible.com.pem
common_name: ansible.com
- openssl_certificate:
path: /tmp/ansible.com.crt
privatekey_path: /tmp/ansible.com.pem
csr_path: /tmp/ansible.com.csr
provider: selfsigned
- openssl_privatekey:
path: /tmp/child.com.pem
- openssl_csr:
path: /tmp/child.com.csr
privatekey_path: /tmp/child.com.pem
common_name: child.com
- openssl_certificate:
path: /tmp/child.com.crt
privatekey_path: /tmp/ansible.com.pem
csr_path: /tmp/child.com.csr
provider: selfsigned
But the problem is that child certificate is not valid:
openssl verify -verbose -CAfile /tmp/ansible.com.crt /tmp/child.com.crt
/tmp/child.com.crt: CN = child.com
error 18 at 0 depth lookup:self signed certificate
OK
I am using Ansible 2.6.1
A self-signed certificate is a self-signed certificate regardless of what key you provided for signing (this key is never verified anyway, because "you trust the certificate directly").
If you check the contents of the child.com.crt certificate with openssl x509 -in /tmp/child.com.crt -text -noout command, you'll see:
Certificate:
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=child.com
Subject: CN=child.com
not Issuer: CN=ansible.com (and there is no way to know whose key it is during the signing task, based on the key alone ― a key is just a random number; you'd need to provide the certificate of the signing party somewhere in the task, which you don't).
What you want to achieve will be possible in Ansible 2.7 with a new provider ownca introduced by this commit:
The 'ownca' provider is intended for generate OpenSSL certificate signed with your own CA (Certificate Authority) certificate (self-signed certificate).
[ ]
Example:
- name: Generate an OpenSSL certificate signed with your own CA certificate
openssl_certificate:
path: /etc/ssl/crt/ansible.com.crt
csr_path: /etc/ssl/csr/ansible.com.csr
ownca_path: /etc/ssl/crt/ansible_CA.crt
ownca_privatekey_path: /etc/ssl/private/ansible_CA.pem
provider: ownca
For now (up to Ansible 2.6.x) you need to call openssl x509 -req (see examples) with the command module.
I have two files with me. One is domain.pfx and another one is domain.cer. To convert my website from http to https through cPanel, I need Certificate (CRT), Private Key (KEY), Certificate Authority Bundle: (CABUNDLE). How to generate these files from the two files that I have?
PFX content: Your domain.pfx should contain everything(Certificate, private key, Ca-chain), you can check with: openssl pkcs12 -info -in keyStore.p12
Key file: openssl pkcs12 -in domain.pfx -nocerts -out domain.key
Certificate:openssl pkcs12 -in domain.pfx -clcerts -nokeys -out domain.crt
CA bundle:
openssl pkcs12 -in domain.pfx -cacerts -nokeys -out cabundle.pem