I'm trying to enable push notifications in my app, the problem is that I can't generate the certificate because whenever I upload my CSR (generated from Windows) I get the following error:
Invalid CSR Select a valid Certificate Signing Request.
The CSR was generated using the following specs:
Key Size 2048 bit
RSA Algorithm
I did the same process last year and I was able to generate the certificate but now all I get is the error above.. did Apple change anything about the CSR or am I missing something?
found it........
The CSR first and last line were:
-----BEGIN NEW CERTIFICATE REQUEST-----
.
.
.
-----END NEW CERTIFICATE REQUEST-----
I had to remove the NEW word and it worked, I was able to generate the .cer file
Related
At present our android build export format is .apk format. I was able to successfully take apk build v1 & v2 signature. From Aug 1st 2021 onwards google discontinues .apk and need everyone should migrate to .aab bundle file. So when same keystore file I used to generate .apk file, I am getting below error
The security strength of SHA-1 digest algorithm is not sufficient for this key size
Detailed error message:
Execution failed for task ':app:signReleaseBundle'.
> A failure occurred while executing
com.android.build.gradle.internal.tasks.FinalizeBundleTask$BundleToolRunnable
> Failed to generate v1 signature
Is there a way to edit the key size of SHA-1 digest algorithm inside the keystore file?
Any other workaround for issue?[like disabling V1 signature]
You will have to create a new key.
I had the same problem. After I created a new jks keystore file I was able to sign the bundle. See here for how to create a new key.
I have generated a certificate for apache with
openssl ca -config openssl.conf -extensions usr_cert -in reqs/httpd.req -out httpd.pem -startdate 170226000000Z -enddate 180226000000Z -noemailDN
This certificate is accepted by openssl, chrome, git etc. but not by firefox which rejects it with:
xxx uses an invalid security certificate.
The certificate will not be valid until 26.02.2017 01:00.
The current time is 26.02.2017 11:49. Error code: SEC_ERROR_INVALID_TIME
This seems to have something to do with the encoding of the notBefore and notAfter fields (https://bugzilla.mozilla.org/show_bug.cgi?id=1152515) but I've been unable to find any hints to on how to fix this but this really helpful
Re-generate the certificate with valid encodings for time fields
(https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates)
Any advice / hints appreciated!
Got an alert on server that the certificate is going to expire. I click the "renew" button and it says Unknown Error. So I dig deeper and run the following on the command line
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/certadmin --recreate-CA-signed-certificate "macserver.local Code Signing Certificate" "IntermediateCA_MACSERVER.LOCAL_1" dd3d0ec3
to which i got the following error:
/Applications/Server.app/Contents/ServerRoot/usr/sbin/certadmin --recreate-CA-signed-certificate: Unable to renew identity 'macserver.local Code Signing Certificate': unable to renew certificate: could not find original certificate 'macserver.local Code Signing Certificate' with serial number 'dd3d0ec3' issued by 'IntermediateCA_MACSERVER.LOCAL_1' (-25300)
So I run the following to search the certificate and it does find it:
sudo security find-certificate -c "macserver.local Code Signing Certificate"
keychain: "/Library/Keychains/System.keychain"
class: 0x80001000
attributes:
"alis"<blob>="macserver.local Code Signing Certificate"
"cenc"<uint32>=0x00000003
"ctyp"<uint32>=0x00000001
"hpky"<blob>=0xA14502C168EB2D717615AA60535926B760804C8F "\241E\002\301h\353-qv\025\252`SY&\267`\200L\217"
"issu"<blob>=0x308193312A302806035504030C21496E7465726D65646961746543415F46494C455345525645522E4C4F43414C5F3131123010060355040A0C09727472616374696F6E312D302B060355040B0C244D41434F5358204F70656E4469726563746F727920496E7465726D6564696174652043413122302006092A864886F70D010901161361646D696E40727472616374696F6E2E636F6D "0\201\2231*0(\006\003U\004\003\014!IntermediateCA_MACSERVER.LOCAL_11\0220\020\006\003U\004\012\014\011macserver1-0+\006\003U\004\013\014$MACOSX OpenDirectory Intermediate CA1"0 \006\011*\206H\206\367\015\001\011\001\026\023mymacserver#gmail.com"
"labl"<blob>="macserver.local Code Signing Certificate"
"skid"<blob>=<NULL>
"snbr"<blob>=0x00DD3D0EC3 "\000\335=\016\303"
"subj"<blob>=0x30553132303006035504030C2966696C657365727665722E6C6F63616C20436F6465205369676E696E6720436572746966696361746531123010060355040A0C09727472616374696F6E310B3009060355040613025553 "0U1200\006\003U\004\003\014)macserver.local Code Signing Certificate1\0220\020\006\003U\004\012\014\011macserver1\0130\011\006\003U\004\006\023\002US"
Anyone have any ideas on this?
I've solved this problem for my cert. Instead of using hexadecimal, i use decimal. So in your case the serial number should be 3711766211 in decimal.
Hope this will help you too.
Thanks
I'm trying to add all the pem and crt files in /etc/pki/tls/certs to an OpenSSL::X509::Store with this code:
require 'openssl'
store = OpenSSL::X509::Store.new
Dir.glob('/etc/pki/tls/certs/*.{pem,crt}') do |cert_path|
puts cert_path
cert = OpenSSL::X509::Certificate.new(IO.read(cert_path))
store.add_cert(cert)
end
And when it gets to /etc/pki/tls/certs/ca-bundle.trust.crt the OpenSSL::X509::Certificate.new raises this error:
cert_test.rb:6:in `initialize': nested asn1 error (OpenSSL::X509::CertificateError)
from cert_test.rb:6:in `new'
from cert_test.rb:6:in `block in <main>'
from cert_test.rb:4:in `glob'
from cert_test.rb:4:in `<main>'
Anyone know what that ca-bundle.trust.crt is or why ruby's openssl can't read it?
For what it's worth, I don't get any errors when I run:
openssl x509 -text -in /etc/pki/tls/certs/ca-bundle.trust.crt
It is a bundle of "Trusted Certificates".
The x509 man page talks about them some.
TRUST SETTINGS
Please note these options are currently experimental and may well change.
A trusted certificate is an ordinary certificate which has several additional pieces of information attached to it such as the permitted and prohibited uses of the certificate and an "alias".
Normally when a certificate is being verified at least one certificate must be "trusted". By default a trusted certificate must be stored locally and must be a root CA: any certificate chain ending in this CA is then usable for any purpose.
Trust settings currently are only used with a root CA. They allow a finer control over the purposes the root CA can be used for. For example a CA may be trusted for SSL client but not SSL server use.
See the description of the verify utility for more information on the meaning of trust settings.
Future versions of OpenSSL will recognize trust settings on any certificate: not just root CAs.
and
The PEM format uses the header and footer lines:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
it will also handle files containing:
-----BEGIN X509 CERTIFICATE-----
-----END X509 CERTIFICATE-----
Trusted certificates have the lines
-----BEGIN TRUSTED CERTIFICATE-----
-----END TRUSTED CERTIFICATE-----
When deploying an APNS certificate in a .wlapp file in MFP 7.0, I'm seeing a null-pointer exception when it validates the end-date, even though it has one. ( openssl pkcs12 -in apns-certificate-sandbox.p12 | openssl x509 -noout -enddate returns a valid date in the future).
It seems others have made this work, so I'm guessing it must be something I am doing wrong...has anyone else resolved similar issues with valid Apple Push Notification Service certs failing to be deployed on MFP
Relevant lines from the log:
947: "com.ibm.worklight.admin.services.ApplicationService E FWLSE3000E: A server error was detected.",
"948: com.ibm.worklight.admin.common.util.exceptions.ValidationException: FWLSE3119E: APNS certificate validation failed. See additional messages for details.",
"949: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validateApnsConfiguration(PushEnvironmentUtil.java:232)",
"950: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validatePushConfiguration(PushEnvironmentUtil.java:220)",
[ ... lots more trace here .. ]
"1030: Caused by: java.lang.NullPointerException",
"1031: at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:117)",
"1032: at com.ibm.worklight.admin.util.PushEnvironmentUtil.getCertificateExpiryDate(PushEnvironmentUtil.java:362)",
"1033: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validateApnsConfiguration(PushEnvironmentUtil.java:230)",
Initial hurdle was that the .wlapp file was not being built, so no apns certificate was in the file (it is just in .zip format with a meta directory that should hold the .p12 file). The underlying issue was that the tag's password field in application-descriptor.xml wasn't exactly right: it was following the example from "Push Notifications in iOS applications" at https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/notifications/push-notifications-native-ios-applications/ :
<pushSender password="apns-certificate-p12 password"/>
when it really should just have the password:
<pushSender password="password"/> </code></pre>
with the file named either apns-certificate-sandbox.p12 or apns-certificate-production.p12 depending on which server is to be used.
Double dumbass on me for not checking the official docs at http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/devref/c_the_application_descriptor.html , which has it described correctly.
Moral: "When in doubt, RTFM"