I have a custom client that i use to get Lets Encrypt certificates but i can't work out the proper protocol to renew the certificates. The versions of the spec that i have found seem very vague on the exact renewal process.
Is the renewal process any different from a new certificate request? Are there steps i can skip or is it totally different? I am currently using the DNS based verification if that makes a difference. At the minute i am just requesting a new certificate following the full process but i am not sure if that the correct way or over kill or a very bad thing to do.
This will depend on your client, however, the steps should be similar to the initial request. The difference is that you don't have to regenerate a private key or a CSR if you saved them and your private key did not get compromised.
This makes it very easy to automate the renewal process.
I believe they will be adding automatic renewal scripts in the near future, there is a basic bash script posted on the front page of the website at the moment.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
During Blockchain Hackathon Kyiv 2020 we picked NEAR Protocol challenge and found several issues.
Accound and account keys are created in web wallet. Then you should run "near login" command at your server which should launch curl to web wallet and authorize near-cli app for accessing keys. However in our case keys weren't imported into server deployed at Digital Ocean with Ubuntu 20.0.4 and accessed via console. Near Discord channel didn't responded to our questions at all. Telegram devs chat support guys didn't helped much, their last offer was "copy keys from localstorage to json file and put into your server .near-credentials folder"
But after all - and that was amazing - a new key created at those remote machine with near addkey command - was added to those accoundID which was not authorized to use app!!! :D
enter image description here
https://examples.near.org/ - GITPOD links doesn't properly configured, not working with errors
https://gitpod.io/#https://github.com/near-examples/token-contract-as
https://gitpod.io/#https://github.com/near-examples/wallet-example
Excited that you chose to build on NEAR, but disheartened to hear about your subpar experience. NEAR is currently growing at an exponential rate and engineering resources certainly can be limited at times.
Unfortunately, if you created your NEAR account on a different machine than the one you want to store the credentials for that account on, running near login won't work. You could get around this by copying your private key from your browser's local storage to the remote machine's browser's local storage, then running near login on that machine but thats a little more work than what’s necessary. The easier, more straightforward path, would be to run near login on your local machine (the one that created the NEAR account) and copy the newly created .json file located in ~/.near-credentials to the target machine. I think that’s what the devs on Telegram you chatted with were referring to. Currently, that would be the easiest solution to that issue.
But after all - and that was amazing - a new key created at those remote machine with near addkey command - was added to those accoundID which was not authorized to use app!!! :D
Could you clarify what exactly happened here and how you performed this action? You should not be able to add a full access key to an account without an existing full access key.
Also, thank you for raising our attention to the two broken GitPod examples. There have been several updates recently to the near-sdk-as dependency these two projects rely on, and looks like something broke. I will make sure this is resolved ASAP!
Please let me know if you have any other questions, comments, or suggestions, and thank you so much for bearing with us as we continue to enhance our platform and developer tooling.
Near Discord channel didn't responded to our questions at all. Telegram devs chat support guys didn't helped much, their last offer was "copy keys from localstorage to json file and put into your server .near-credentials folder"
I would like to point out that there is no paid service with 24/7 support. People have their weekends to spend with their family and friends.
But after all - and that was amazing - a new key created at those remote machine with near addkey command - was added to those accoundID which was not authorized to use app!!!
Which key are you talking about? The 3 keys you have on the screenshot were sequentially used to sign the next transaction adding the new key:
ETQeNJrRiqbcuqJyrfDTh1EYAUAetXZsnuuiEH8T6mnc transaction created the account with ed25519:HBi7mgC... key.
8heaysv121qhFjktwRm9ftF4jA7dgcYRHvKkcCnhXFVT transaction signed with ed25519:HBi7mgC... key (added in (1)) adds a new ed25519:DmNJSxx... full-access key.
DUp8VJ9aoUyC6r8ira6udpgHYxsKJWi3LXkxxn5btLW2 transaction signed with ed25519:DmNJSxx... key (added in (2)) adds a new ed25519:DoMh6uC... full-access key.
I want to use the Direct Mail SDK(Java) directly within client application which is distributed across. The way to authenticate users within the application, I need to provide access keys as below,
IClientProfile profile = DefaultProfile.getProfile("cn-hangzhou", "<your accessKey>", "<your accessSecret>");
How can I prevent user to know the Access Keys and still prevent the need of third-party API? Is it possible?
First, it is bad practice to code an application that requires secrets that runs on the client. You should manage everything on the server and provide an API that the client software interfaces with.
Second, there is no way to hide those credentials once passed to the client. You could encrypt the credentials but at some point the client application will need to decrypt them. Even amateur programmers can figure out how you are processing your credentials.
Ignoring the above advice, Alibaba Cloud supports STS which provides temporary access keys. Using your Alibaba credentials, you would call AssumeRole which creates temporary access keys giving the user permission call DirectMail. You can limit the time that the credentials are valid. The range is 900 to 3600 seconds. After that duration the keys become invalid.
Keep in mind that 900 seconds is a long time. A bad actor getting access to those keys could send thousands of emails using your account. Therefore implement strong user authentication, STS and temporary access keys.
If you think that just keeping your interface secret is enough, don't. There are millions of script kiddies on the Internet poking at every IP address. Launch a new ECS instance and you will see attacks within hours.
As you said since it is a Java Web Application(assuming), currently I think of something using similar to JBOSS Vault to store the access keys securely.
If it is some standalone client application still you can use some encryption methodologies to store the data. But this will only prevent easy access to the data/keys. But it is not impossible. The best bet would be creating another third-party API
I've written a Windows TCP (NOT IIS) server program in VB that provides the backend for an enterprise iPhone app that I have also developed. The system utilizes Apple Push Notifications, and that works fine, unless the server reboots for whatever reason.
Part of the Push Notification system is the inclusion of Apple certificates on the server. I followed the steps shown here to install the necessary certificates, and even though it's for ASP.NET applications, it works for my Windows-based server. Except, as I said, a reboot requires installing the certificates all over again.
I found this page on Server Fault that suggests adding a user to the certificate through the MMC snap-in, but that didn't work either.
Two questions: Following the steps shown on the Server Fault page, do I need to add a specific user? The only users that pop up are SYSTEM (which I tried), Administrators(ComputerName/Administrators) (also tried) and "S-1-1-5-blah, blah" (didn't try). Would there need to be a different user added to make it work?
Q2: If this won't ever work, is there a different way?
Full disclosure: This is the second time I have submitted this question, but the previous one (four months ago) was never responded to. I'm hoping someone who knows will see this.
Thanks for any advice.
AFTERTHOUGHT: The instructions I linked to above say to install the certificates to Personal/Certificates. Maybe this is wrong? This stuff is way over my head, so I don't understand the function of all the different stores.
Found the problem.
The page on Server Fault left out something. I needed to add a user that the system would recognize to the Permissions list. I added my user authentication, selected it, and after that the certificate persisted after a restart.
It is at least working on my development server. I haven't tried it yet on my production server.
Update: Works the same on the production server. Also, instead of using my user authentication, I used the IUSR authentication, meaning that it should work even after my name is removed from the active directory.
Our organization has a number of Rails applications (websites) deployed to Heroku. A former devleoper has left the organization, and as good practice we want to change the Heroku API key associated with our account to prevent any modifications to the apps via the Heroku CLI.
I know that the Heroku API Key is used for Heroku CLI access (it gets cached in ~/.heroku/credentials), but not certain what else it is used for. Specifically, do 3rd-party add-ons in the Heroku platform (e.g. New Relic, Hoptoad/Airbrake, Sendgrid, etc) use this, and therefore require reconfiguring if the API Key is changed? Heroku throws up a fairly generic (and non-informative) error message when you click the "regenerate" button to change it.
Because the term "API Key" is so generic, want to be clear that this is the single API Key associated with each Heroku account accessible via "My Account" link. Image (and warning message) below.
Asked Heroku Support. This is what I got back:
"you can safely change your API key at any time, as we don't give it to any add-on providers. That alert is meant to remind you that if you added your API key to any application or service (ie for auto scaling, manually provision workers, etc) it will stop working until you provide it a new key."
I requested that they update the interface/documentation to make this more clear.
Also remove him from being a collaborator on all your projects so he can't push to them via git.
Out of curiousity (i'd never seen reset key in the admin) I tried it. When I then tried to use the CLI against one of my apps I was asked to reauthenticate - but i can't now get back in - doh! The same username/password works via the site. I'll ping support and report back,
UPDATE:
So it appears my problem is entirely due to the Heroku Accounts (https://github.com/ddollar/heroku-accounts) plugin that I'm using which stores a copy of the key in the ~/.heroku/accounts/ file. Support got me to remove the folder and it all works now - just something to be aware of if you reset your API key.
We are working on a service that will have website access for stats and other tasks, but the majority of use will be through a client gem and rake tasks. What is the best way to handle authentication for both pieces.
It looks like fiveruns_tuneup, getexceptional, New Relic and others have websites with username and pass, but use API keys stored in ./config/serviceName.yml Any reasons it is better to have API keys opposed to user/pass in the config (do they use keys because often the key is checked into SCM and used across the project, where ours would not be checked in and would be a per user setting)
GitHub has you put your public key on the github servers and uses that, but I think git supports public/private key by default.
Would it be preferred to keep a ./config/serviceName.yml or since we have to create a subdirectory with other information have ./serviceName/config.yml? (does the per user, not stored in SCM mean it is better to keep it all in one excluded directory?)
Just looking for some thoughts and ideas on best practices before starting implementation.
I recommend that you use username/password combos for website accounts, and API keys for any web services. Here are the advantages of this technique:
By linking API keys to an account, you could have many API keys for the same user. Perhaps this could be used for many remote web servers that consume this data service, or to perform unique tracking.
Attaching API keys to an account also lets you keep the user's username and password uncompromised since an API key will not contain them. Many users use the same username and password on many services, so you are helping to protect them.
You could limit access to portions of functionality for each API key, but give their username access to everything their account should have access to. Additionally, you can even give them the ability to limit how much access an API key might have.
Most of the major services (Yahoo! API, Flickr, Google API, etc) use accounts with a username and password to login to the web account, and API keys for integration points.
Never use user/pass when you can help it. The security issues are horrible. If the user/pass leaks out, you have to change your password or they get access to your whole account.
API keys are better because they're easier to change and can be limited to only the part you need access to with the APIs (ie, if someone has your password they can change your password. They can't if they just have an API key).
Different API key per client or secure token exchange (such as OAuth) is the best solution if you'll have more than just your client on the API.
The github approach is bootstrapping on top of existing git practices, however it's not a bad idea since presumably each user will have their own private key to match a published public one in the central authority. Since key-agent's already furnish a means of safe authentication this seems like a very safe approach. Public/private keys are a well thought out authentication scheme, which has unfortunately been reinvented many times to limited success.
The problem with the API key is that anyone who gets a copy of the API key can do whatever that authorizes. Storing the API key somewhere in the project begs the users to share a key. If you are associating public keys with a user, it is possible to grant rights to the client on a per user basis, and a proper key-agent approach suggests that those will not be stored in an SCM anywhere.
I'm not sure I follow what the distinction between config/serviceName.yml, or serviceName/config.yml is. It doesn't seem as if it would be pertinent if you have public/private keys as an authentication method for the client.