I develop embedded firmware, that works with google cloud iot. I used this example https://www.st.com/en/embedded-software/x-cube-gcp.html?ecmp=tt9470_gl_link_feb2019&rt=um&id=UM2441 as a base for my firmware. I have a problem in understanding how the firmware should use root CA certification package (this is described here https://cloud.google.com/iot/docs/how-tos/mqtt-bridge#downloading_mqtt_server_certificates). Google suggest to use this package https://pki.goog/roots.pem to connect to mqtt server. But this file is too big for embedded firmware. In the stm32 example smaller file is used, it contents only 2 certificates:
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIF3jCCA8agAwIBAgIQAf1tMPyjylGoG7xkDjUDLTANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTAw
MjAxMDAwMDAwWhcNMzgwMTE4MjM1OTU5WjCBiDELMAkGA1UEBhMCVVMxEzARBgNV
BAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVU
aGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBSU0EgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQCAEmUXNg7D2wiz0KxXDXbtzSfTTK1Qg2HiqiBNCS1kCdzOiZ/MPans9s/B
3PHTsdZ7NygRK0faOca8Ohm0X6a9fZ2jY0K2dvKpOyuR+OJv0OwWIJAJPuLodMkY
tJHUYmTbf6MG8YgYapAiPLz+E/CHFHv25B+O1ORRxhFnRghRy4YUVD+8M/5+bJz/
Fp0YvVGONaanZshyZ9shZrHUm3gDwFA66Mzw3LyeTP6vBZY1H1dat//O+T23LLb2
VN3I5xI6Ta5MirdcmrS3ID3KfyI0rn47aGYBROcBTkZTmzNg95S+UzeQc0PzMsNT
79uq/nROacdrjGCT3sTHDN/hMq7MkztReJVni+49Vv4M0GkPGw/zJSZrM233bkf6
c0Plfg6lZrEpfDKEY1WJxA3Bk1QwGROs0303p+tdOmw1XNtB1xLaqUkL39iAigmT
Yo61Zs8liM2EuLE/pDkP2QKe6xJMlXzzawWpXhaDzLhn4ugTncxbgtNMs+1b/97l
c6wjOy0AvzVVdAlJ2ElYGn+SNuZRkg7zJn0cTRe8yexDJtC/QV9AqURE9JnnV4ee
UB9XVKg+/XRjL7FQZQnmWEIuQxpMtPAlR1n6BB6T1CZGSlCBst6+eLf8ZxXhyVeE
Hg9j1uliutZfVS7qXMYoCAQlObgOK6nyTJccBz8NUvXt7y+CDwIDAQABo0IwQDAd
BgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rIDZsswDgYDVR0PAQH/BAQDAgEGMA8G
A1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEMBQADggIBAFzUfA3P9wF9QZllDHPF
Up/L+M+ZBn8b2kMVn54CVVeWFPFSPCeHlCjtHzoBN6J2/FNQwISbxmtOuowhT6KO
VWKR82kV2LyI48SqC/3vqOlLVSoGIG1VeCkZ7l8wXEskEVX/JJpuXior7gtNn3/3
ATiUFJVDBwn7YKnuHKsSjKCaXqeYalltiz8I+8jRRa8YFWSQEg9zKC7F4iRO/Fjs
8PRF/iKz6y+O0tlFYQXBl2+odnKPi4w2r78NBc5xjeambx9spnFixdjQg3IM8WcR
iQycE0xyNN+81XHfqnHd4blsjDwSXWXavVcStkNr/+XeTWYRUc+ZruwXtuhxkYze
Sf7dNXGiFSeUHM9h4ya7b6NnJSFd5t0dCy5oGzuCr+yDZ4XUmFF0sbmZgIn/f3gZ
XHlKYC6SQK5MNyosycdiyA5d9zZbyuAlJQG03RoHnHcAP9Dc1ew91Pq7P8yF1m9/
qS3fuQL39ZeatTXaw2ewh0qpKJ4jjv9cJ2vhsE/zB+4ALtRZh8tSQZXq9EfX7mRB
VXyNWQKV3WKdwrnuWih0hKWbt5DHDAff9Yk2dDLWKMGwsAvgnEzDHNb842m1R0aB
L6KCq9NjRHDEjf8tM7qtj3u1cIiuPhnPQCjY/MiQu12ZIvVS5ljFH4gxQ+6IHdfG
jjxDah2nGN59PRbxYvnKkKj9
-----END CERTIFICATE-----
I have found this 2 certificates in google package https://pki.goog/roots.pem. Does this mean that I can use any certificate from package? And what will happen after updating active certificate in google cloud, as described here Why won't my Raspberry Pi connect to Google Cloud IoT?. I have already faced a problem with connection to cloud for a some days, but now it works ok again.
I saw that google suggest another way for embedded devices (long-term MQTT domain with minimal root CA set), but it requires to do some changes in firmware and it is difficult now for me.
I see that you mentioned that changing the firmware is hard, and that is true, but there isn't a good way other than this because of the rotation of the general root certificate. Even if you trim the currently unused certs from the CA file, once rotation happens, and it happens frequently, it'll break connectivity.
From this page: https://cloud.google.com/iot/docs/how-tos/mqtt-bridge
Google's minimal root CA set (<1 KB) for mqtt.2030.ltsapis.goog. The minimal root CA set includes a primary and backup certificate.
This set is for devices with memory constraints, like microcontrollers, and establishes the chain of trust to communicate with Cloud IoT Core only.
Devices with the minimal root CA set communicate with the Cloud IoT Core via long-term support domains.
This set is fixed through 2030 (the primary and backup certificates won't change). For added security, Google Trust Services may switch between the primary and backup certificates at any time without notice.
Which is what you need to use for embedded systems that you don't want to deal with rotating certificates every time the core Google root CA rotates certificates. Here are the links for the primary and backup root certs:
https://pki.goog/gtsltsr/gtsltsr.crt
https://pki.goog/gsr4/GSR4.crt
Note also that this uses that different endpoint for this certificate. The general (128K) root cert is used when connecting to mqtt.googleapis.com, and the smaller long-term support root CA uses mqtt.2030.ltsapis.goog so you'll need to change your firmware to account for this.
Related
Hello Corda experts: I have a question about Conclave beta 3. I downloaded conclave SDK hello world project, and ran it according to conclave document successfully. But when I tried to use RestTemplate to access an external https API from the enclave, it is failed. And the error message is "java.security.NoSuchAlgorithmException: Default SSLContext not available". Since the default JVM for enclave is Avian, I doubt that maybe Avian doesn't support SSL. Does any expert know the root cause and how to solve it? Thanks very much.
At this time Conclave doesn't support outbound SSL connections. It's something we'd like to support and is a high priority but it must be done very carefully. For example, we will have to ship a root cert store with the enclave embedded in the binary (or a signed version that's injectable by the host), there are questions about how to handle expiry checking given that the host controls the clock, whatever credentials are used to access the external service (if any) need to be securely sealed and stored, it will only make sense to support OCSP Stapling as a form of revocation checking with all others needing to be disabled and so on.
You don't technically need us to solve these issues for you. You can load the SSLEngine and relay packets from it in and out of the host using the call mechanism. It'd be a bit awkward but should be possible.
My client is asking me to fill out a form in order to setup the VPN and make sure that our configuration values are compatible. They've sent me a list of configuration values for the VPN using IKE v1 that they use, such as
Mode
Encryption Algorithm for Phase 1
Hashing Algorithm
Diffie-Hellman Group
.....
I've setup these variables in a previous VPN using ipsec on CentOS, but on Google Cloud VPN I haven't found anything related to this. The documentation doesn't mention that you could configure these values, nor it says which values does it use on its own. So, how could I know which values are supported on Google Cloud VPN in order to make sure they are compatible to what my client is requesting from us?
You can find the desire configuration here:
https://cloud.google.com/compute/docs/vpn/advanced#supported_ike_ciphers
Firstly, thank you for the taking the time out to read this post.
I'm running a demo development web server which is hosting my ASP.net Web API in IIS8.
My API is setup to work only via SSL, but I need the self signed SSL key to be 1024 bits rather than 2048 due to the limitations of my Microchip PIC Microcontroller that connects to it.
Can anyone advise me on how I can generate a self signed SSL certificate to be 1024 bits rather than the default 2048?
Please note that I am new to network/web programming so I'm trying to work things out as I go along. Thus far this is my first demo web applications.
Many thanks,
Rob
Ok I managed to create a key size of 1024 using microsofts selfssl tool which is part of their IIS6 Resource Toolkit.
This has solved my problem.
So, considering the pricing for SSLs, I chose to try creating my own SSL certificate (still in the works).
Once I get that part done, how to I get the EV and green bar aspect of the certificate set up?
It can make sense to create your own certificates (and use your own CA) if you're in an environment where your users can import your own CA certificate in a way they can verify it independently. Typically, this works fine on an institution's network where someone installs the extra CA certificate as part of the OS configuration when configuring centrally-administered machines (and similar cases). Under these conditions, this will get you a blue bar without any problem.
Extended Validation certificate (which produce a green bar) rely on two things:
Extra policy attributes in the certificate: technically, you could define some OIDs yourself, although getting others to recognise it will be a problem, obviously.
OID policies and root certificate fingerprints that are hard-coded in the browser.
This second point is what will prevent you from doing it yourself. Non-EV certificates is something you could potentially implement on machines under your control using a few extra configuration steps. EV certificates also require that you control the compilation of the browser: this is not going to happen for proprietary browsers such as IE, and it can still be quite a lot of work for open-source browsers (e.g. Firefox/Chromium), since you wouldn't be able to rely on the pre-compiled binaries (and you'd have to recompile it yourself for every new release).
I think you're probably going to find that all that nice stuff (assuming you are talking about the padlock and green bar in the browser) depends on the other part of certification, the fact that the certificate has been issued by a trusted provider who has verified your identity - this you probably can't do on your own.
The whole idea of SSL certificates is that somebody everybody trusts (mozilla, microsoft) certify certifiers (thawte etc) to certify sites they audit (somehow) as being genuine. This wont work with your certificate, the idea is a trust chain. microsoft trusts thawte, they trust you. Nobody trusts you in your case so your self-signed certificate means nothing to browsers.
Some phones only prompt the user for permission the first time a connection is made. Others pop up the permission prompt whenever the MIDlet attempts to make a HTTP connection! What are the options if we want to suppress the prompt?
Can we sign the JAR using only one CA (Certificate Authority) and have it work on all devices? Do we have to pay for a signature on every release?
Is it an option to create our own CA certificate and tell our customers to install it on there device?
Alternatively, it seems that plain socket connections do not suffer so. Is there a free implementation of HTTP on top of TCP for J2ME?
Some phones allow you to change the setting manually to set once per session. Or try adding
MIDlet-Permissions: javax.microedition.io.connector.http
to the jad file.
Yes, if the build is signed with the root certificate that is available on most devices, Verisign Class 3 certificate, for example
As a security measure, devices don't allow you to install your own certificates, even if it is obtained from a CA.
Plain socket connections may add overhead in processing of the data in the client side. Also some security issues are also involved.
Signing the JAR is not guaranteed to suppress these prompts on all handsets and all networks. It may work on some. AFAIK you usually need to sign per build; so if you use the same build on many handsets, you need to sign only once.
You could write your own implementation of HTTP over sockets, but beware that Socket implementations do not allow access to ports 80 and 8080 (again AFAIK).
Your best option when experiencing multiple prompts for HTTP is to direct the user to the MIDlet permissions setting in their handset menu; this should be changed to "ask once".
HTH,
funkybro
Java Verifieds UTI root certificate is not on all handsets/network combinations, the same is true for other domains in the trusted third party such as Verisign and Thawte (for these bodies in particular Motorola devices)
It is fair to say that the UTI certificate is probably the one to choose to give you the most coverage across handsets
To suppress the HTTP connection prompt, signing an app is the only option. Another would be to get preload on a pre-market phone, but even the handset manufacturers require signed jad/jars.
Making a set of jad/jar work on different devices is not dependent on signing but how you design an app. If you can address this then yes, you can have one signed jad/jar work on multiple devices.
I do not know about creating our own certs and asking customers to install them. I dont think it works as I dont think it is possible.
HTTP over TCP is a fairly easy implementation, provided you know what you are doing, but I dont know of any free implementations of it.
Get it Java Verified and you will find that on all networks and phones - the user will get prompted only once each time they start the app to authorise a connection.