Reusing SSL Certificate - deployment

My team is building a web application for our capstone project. We deployed it to digitalocean using dokku, everything was fine but one of us(aka me) accidentally deleted the database. Since my team and I don't know anything about deployment, we ended up hitting our rate limit on letsencrypt for the certificates trying to redeploy. Reading through there documentation it says we have to wait a week before being able to get another certificate. I was wondering if it was possible to find the certificates that was issued and applying to the domain? Or if there is another solution? Thank you.

Related

Can you install an SSL certificate on a server other than where the CSR was generated?

I have recently been tasked with automating our certificate issuance/renewal process via PowerShell. Having never worked in this space prior, I'm doing a lot of on the fly learning.
The idea is to make the execution stateless, meaning we can have one server running a script that requests certificates and simply store them to be installed on the appropriate machines later. That will likely be automated as well. My question is this: when I generate a CSR on the server, and the certificate is ultimately issued by DigiCert, can that certificate only be installed on that server? My research says yes, and yet I tested this by installing an already issued certificate on my local machine and it worked. I had not generated the CSR for that certificate on my machine, yet I was able to install it without error. Would the problems only come in when binding the certificate to a site?
Any insight would be greatly appreciated.

How could I get code of the application deployed on digital ocean?

I need to edit application developed by somebody else in Meteor.js deployed on Digitalocean. I have an access to digitalocean account, but have no idea how to access code and the whole folder where is application stored. Is this even possible ? Should I ask him for github repo with the app to get it instead ? Thanks.
Ask for the repo. The server may only contain the built version of the app (since that's all that's needed to run it) and that's no good for developing. You can't edit that directly.

Is it acceptable practice to install an Authenticode code signing certificate directly on my build server to create a production signed build?

Is it acceptable practice to install an Authenticode code signing certificate directly on a build server to create a production signed build? I’m looking for some resources on the net that suggest or support that this practice is legitimate providing you’ve taken appropriate steps to secure the build server and the process by which a build is created and deployed.
All the “best practice” guidance I can find about code signing practices are way over the top in terms of suggested process. Microsoft’s reference document has as many as 6 servers in play for the simple act of signing a single assembly. http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
Some background:
My company creates simple rich-client line of business applications for its employees and direct customers. We do not create commercial software. My build server is physically secured and network secured using my companies strict security policies and procedures. Only very specific people in the organization have the ability to even start a build in my environment.
Our current process requires me to break a build/deploy process into many stages with a lot of manual process in place. We use physical devices to store the Authenticode certificates, requiring user-entered PINs to access. We have to shuffle the assemblies/manifests that require code signing to designated code signing PCs which also have to be physically secured.
To me, it is less secure to pass around a physical token/device and leave all these manual steps in place. There is nothing stopping a person with physical access to the token/device from signing anything they want. At least, with an automated, logged, controlled build server environment, you know what was signed and by who.
The main problem with installing a certificate on a build server and making it accessible to a build account, is that now any developer can sign any malicious piece of code by temporarily commiting it to some legitimate project, and reverting it back after the build.
No matter the actions are logged, the breach is hard to identify or prevent. Especially if development is active and several builds are done per day.
The only solution I can think of is to limit a number of people who can trigger an "RTM" build. Other build types may use a test certificate or avoid signing at all.
In fact, this is the question I bother my head too.

Command line installation of Code Signing certificates, .p12 files, and mobileprovisions

I work at a company who does 3rd party iOS development for various enterprises. I've been tasked with researching a better way to build and deploy code to these enterprises. Based on the Apple TOS, they cannot use an application signed with our Enterprise certificate (they're not "in house"). The code needs to be signed with their (our clients) Enterprise certificate. Here are a few possible solutions I've seen -
1) Send the code to the client, and have the client build it. This is a no-go.
2) Create a library with the application code and send the .so file, and the headers, to the client for building. We're currently doing it this way but are looking at making this easier on the client/us.
3) Have the client send us their certificate, mobileprovision, and .p12 file and then we build the application using their certificate. This could work but could become a management nightmare.
We've come up with an idea that is kind of a mix of these ideas. The idea involves building a customer portal where the client can upload their files (cert, p12, provision) to our Mac server and the Mac will automagically build their application, properly signed. The problem I'm having, however, is I can't seem to find out how to automate the installation of certificates and provisions.
So with that said, does anyone know of a way to install a CodeSign certificate (with a .p12 file) and a mobile provision file from the command line? Once installed is there also a way to remove the items from the command line?
Any help, ideas, and/or input would be greatly appreciated. Thanks!
You should be able to manage those resources in the keychain using the security (http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/security.1.html) command. The script I'm using to control command line builds might be a useful reference: https://gist.github.com/949831
Admittedly I've only ever had a maximum 2 external clients plus my own stuff at one time, so it was mostly only the same nightmare that it usually is by default, but how bad would it be if you had to manually do everything EXCEPT the provisioning profiles? In my experience once the client certs got added I never really messed with them again even with new projects (from the same clients.)
You could handle the provisioning profiles by simply copying the files into ~/Library/MobileDevice/Provisioning Profiles, and deleting them when no longer needed. It sounds like you are already set up to automate that process.
If you're currently installing the provisioning profiles by "dropping them onto xcode" I'd suggest you do it by copying into the folder anyway, because then the file names are preserved and so you actually can tell what you have installed by simply looking at the folder.

Move ClickOnce repository without reinstall in client machines. Is it possible?

I have a C# application (WinForms) (ClickOnce) whose repository is installed on a server that is about to crash, so my boss asked me to move the repository, but there are around 300 client machines which have the application installed.
The ClickOnce is signed with a Test Certificate.
Is it possible to move the repository without having to reinstall in the client machines?
Thanks in Advance
[EDIT]
I Have published the application to the new server, but the clients don't reach it, what else can I do? I think i should change something inside the manifest or something like that, but a actually don't know too much about ClickOnce... In any case, i would like to avoid the reinstallation on all the client machines, any ideas, suggestion? thanks in advance
The answer provided by Jhonny seemed promising to me, and I encountered an error when I tried it, which I had to solve. It had to do with certificates.
After following his setps, when I launch the ClickOnce app on the client machine, I get an error dialog: "Cannot Start Application".
When I click on the Details... button in the error dialog, the text file that opens shows that the app is trying to update from the Deployment Provider URL of the new server, but it gives this error:
"The deployment identity does not match the subscription."
The problem was the certificate used to publish the app on the old server was expired, and I had updated the certificate in the app published on the new server. The certificates didn't match.
The solution was to first publish the app to the old server with the new certificate, have the users open the app to get that update, then publish another new version with the Deployment URL of the new server, and copy the files to both servers. When the users updated the next time, they got the version of the app from the old server with the manifest pointing to the new server, and then, all subsequents updates were retrieved from the new server.
Here is what I have done, for people who may have the same issue.
Setup the new server on the publish package. (Project Properties, Publish Tab)
Publish to the new server
Copy the published files to the old server. (Include the .application file and the folder)
When the clients reach the old server, they will update, but the server location will be updated on the client to the new server name.
You could try to change the DNS alias so that it redirects to your new server.
The fact that the code signed using a certificate is not relevant, since code-signing certificates are not bound to a specific repository (as opposed to SSL certificates)
Btw, why don't you want to reinstall? The whole point of clickonce is to ease this kind of software update !!