My goal is to update the Certificate for Exchange Servers from within a C# app, just like the Enable-ExchangeCertificate PS Cmdlet does.
I've already written an updater for IIS, which uses Microsoft.Web.Administration to access and manipulate IIS Sites and Bindings. I've searched through Google and VS Libraries for Exchange API tools, but without any luck. I can only find References to EWS (Exchange Web Services), which can't update the Server Certificate AFAIK.
Is there any API that can be used? How does Enable-ExchangeCertificate provide the functionality? I'm also thinking about just using the PS Cmdlet if all else fails, but I'd like to have a standalone app to rely on. No remote server management needed, localhost-only is fine.
tl;dr How to update a local Exchange Server Certificate in C#?
EDIT I'll look further into the EWS API (https://github.com/OfficeDev/ews-managed-api/blob/master/README.md), it looks like it might do the job. It provides Assemblies to access EWS data, but I haven't found any API Calls exclusively for Certificate Management.
There are multiple parts in MS Exchange which aren´t covered by an API. Mostly this is due to security reasons or as it´s quite complex and therefore no API needed (e.g. Exchange Schema update).
The normal Microsoft way included only two steps:
Make a Backup of the current configuration & SSL cert (Optional)
Import the certificate
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path
c:\certificates\YOUR_CERTIFICATE.cer -Encoding byte -ReadCount 0))
But some use MMC and that's working as well (so you might check for an API for MMC for this part).
Enable it
Enable-ExchangeCertificate -Thumbprint
1234ae0567a72fccb75b1d0198628675333d010e -Services POP,IMAP,SMTP,IIS
I would assume that there is no such API as its not really needed to have one. Normally an SSL certificate is valid for 3 years. So you need to run the command above 1x every 3 years and a 3rd party access to this part wouldn´t make any sense as it wouldn´t be often used and therefore Microsoft haven´t build one.
To give you more infos here. The SSL certificate information for Microsoft is saved in two locations. One in the local Regestry and one in Microsoft Active Directory (see here: uses the local instance of Active Directory Lightweight Directory Services (AD LDS) to read and write data). Dealing with changes to the ActiveDirectory without the way Microsoft supports might be VERY risky and would mean that Microsoft do not offer any support if that caused a problem. So I would use the powershell approach Enable-ExchangeCertificate in your app.
P.S. I would never ever run an unknown plugin on my Exchange server which do replace an SSL certificate which I can do via a simple powershell command. The plugin could cause a lot of other issues and can contain a lot of stuff which isn´t so "nice". So before you wast your time into that project think if there is really an audience for it.
Related
I have the following requirement: in an existing webapplication we have a user management. In this you should be able to say for user xyz he should have access to an SFTP-Server lets say with a checkbox option: Allow access to SFTP.
If the option gets selected it should do the following thing:
-> Create a login on the SFTP-Server User: xyz Passwort xzy
-> Create a folder for user /root/xyz with read and write permission (isolated from others)
Anyone has done something similar or an idea how to archive this? What I found so far is .NET FTP authentication which works with IIS (but seems IIS supports only FTP/S not SFTP).
The SFTP is not set up by now, so could be any (prefered on another server)
Would appreciate any help :)
Seems like what you need is an SFTP (thus SSH) server that allows you to create users via some sort of command-line or - better - via remote calls. Depending on the server there may be several ways to do that.
if the server allows you to have SSH shell access (which I would strongly discourage!!) then you could open a shell and on it and use your OS/server command line tools to create/manage user profiles there
if the server has its own CLI (command-line interface) and such CLI allows for remote configuration, then you could invoke it from your web application (make sure permissions allow you to do so) and do it that way
the best way to do it, though, would be to have a server that can be configured via REST API, so you could simply call such REST API from within the context of your web application, and manage your SFTP server's users that way
Since you have not deployed your SFTP server yet, and if you have the liberty to pick any SFTP server you see fit, then you may want to try Syncplify.me Server!, which gives you all 3 options listed above.
(disclaimer: I work at Syncplify)
I currently have an in house C# app that is delivered via click-once. I'm moving to the cloud and would like to have the Click-Once delivered from there (will be accessed from multiple countries and I can't use IP ranges to block out intruders), but it appears that the only way to secure the download is using windows security which is not an option for my clients.
I'm looking for a nice way to deliver the initial software and then keep the clients updated.
I've heard about WIX but I can't seem to find any information around updates from the internet and it.
Does WIX support this? If so can someone point me at an example or reference?
If it doesn't support it is there another solution someone can recommend?
Here is my usage scenario:
- User logs into a website supplying credentials, (username/password or certificate) then has the ability to download and install the application.
The application must check on startup of the app for a new version and if there is automatically download, install then run it. (would be nice if the user must resupply credentials for the update but not a necessity)
Bonus points if it will work on any web server such as a simple Node.js implementation.
WiX Only handles the installation via the bootstrapper or MSI you have generated, so I would assume that it's most likely a windows installer setting of some kind when it is first created. The element ClickThrough is supposed to be able to handle this scenario, though I don't know much about that.
The way my work colleagues dealt with this is by using IIS and an ASP.NET web service, along with a DLL that has methods to check with the web service if there is an update, and then prompts the user about the update and asks if they wish to update (did I say update enough in that sentence?).
Hope this helps.
I would like to timestamp my DLL file with my own Authenticode Timestamping Service. Is this possible? How could I achieve this?
You can develop your own timestamping service. You can write TSP (RFC 3161) server but Authenticode doesn't use RFC 3161 but PKCS#7/PKCS#9 formats as described in MSDN article (which you can implement as well). Our SecureBlackbox components include timestamping server component which supports both formats. Update: recent updates to Authenticode use standard RFC 3161 timestamps.
But the problem is to get the certificate which you will use to sign timestamps. This certificate must be issued by one of the CAs and as I understand, there exist severe requirements regarding management and infrastructure aspects of running a timestamp server. In particular you need to have a secure timestamping hardware. I didn't dig deep into this question, but these aspects are much more complicated then writing a piece of code.
Still if you run your own PKI infrastructure (have your own trusted root certificates and CA certificates), then the problem of having a trusted timestamping certificate is solved automatically - you can generate your own certificate.
You need to write a custom HTTP Timestamp server. It should follow RFC 3161 Time-Stamp Protocol (TSP) rules.
When you sign your DLL for authenticode with a tool such as Signtool.exe from the Windows SDK, you can specify the url of the timestamp server (with the /t swich. See also /tr and /td). You would then point to your server.
See here on SO for a related question: Trusted Timestamps - understanding the format (rfc3161)
and also: Alternative timestamping services for Authenticode
You can set up your own Time-stamping Authority (TSA) supporting Authenticode time-stamps (and/or RFC#3161) using SignServer.
See https://www.signserver.org for the download and the installation instructions. In summary the important steps are:
Make sure you have the pre-requisites:
Java
An application server (i.e. WildFly)
Apache Ant for deploying
Download the 4.0 release from https://signserver.org or https://sourceforge.net/projects/signserver/files/signserver/4.0/ .
Configure application server
For HTTPS (optional)
To make web services work
Patch with the latest security fixes
Configure SignServer deployment
Set database.name=nodb and database.nodb.location=/an/empty/folder/as/db in conf/signserver_deploy.properties
Deploy SignServer
export APPSRV_HOME=/opt/wildfly-9/
bin/ant deploy
Start application server /opt/wildfly-9/bin/standalone.sh
Check that server started
bin/signserver getstatus brief all
Setup a crypto token
bin/signserver setproperties doc/sample-configs/keystore-crypto-configuration.properties
bin/signserver reload 1
bin/signserver getstatus brief all
Setup a sample time-stamp signer
bin/signserver setproperties doc/sample-configs/qs_timestamp_configuration.properties
bin/signserver reload 2
bin/signserver getstatus brief all
Test the time-stamp signer
bin/signclient timestamp http://localhost:8080/signserver/process?workerName=TimeStampSigner
Assuming you are wanting this for testing, if you are happy to use signtool.exe with the /tr switch, you don't have to look at the RFC, because openssl implements enough of this for you. Simply write an HTTP POST handler in your favourite language, pass the posted data into "openssl ts -reply" verbatim, send back the openssl TS response data. This is good enough to fool "signtool.exe verify /pa", even if it isn't strictly following the RFC.
EDIT: It seems the open-source Java Signserver project gives you a server handling MSauthenticode (/t) and rfc3161 (/tr) timestamping out of the box. Configuration of Signserver involved too many dependencies for me, so I instead hacked its unit test for MSAuthenticode timestamping, bolted on a small HTTP server to the test case, and with little work - my Java skills are mediocre at best - have a running authenticode timestamp server for development use, and have verified that the timestamps thus created are not subject this issue. I cannot release the source code, however following this tip should get you something working pretty quickly.
https://PKIaaS.io offers an RFC 3161 and Microsoft Authenticode compliant timestamp server. After you create a certificate authority on the site, it will show a timestamp URL in the list of "CA Service URLs" that timestamp requests can be sent to for signing.
We have a three tier application entirely developed in .NET 4.0 (C#). As the enterprise application server we use COM+ 1.5 (I know it's a little bit legacy...). There are a server part and a client part both developed in C# for .NET 4.0.
The server part exposes services inheriting the ServicedComponent class and returning objects which implement the "Serializable" attribute. The client calls the remote classes via the COM+ exported proxy of the component. We distribute the client app through ClickOnce and we have to install, with Admin privileges, the COM+ generated Proxy onto every client machine. This is the bad point.
So we are trying to evaluate other techniques which allow us to eliminate this proxy installation but it's not so clear how to do this. We'd like to find a low impact way that allow us to use the same COM+ part and including in some way the Proxy into the client side code.
We have tried to use code like this in the client part but still requires the COM registration.
Type comObjectType = Type.GetTypeFromProgID("SumNameSpace.SumClass", "servercomplus", true);
SumInterface comObject = Activator.CreateInstance(comObjectType) as SumInterface;
We thought that using in the client part the interface instead the class would have to work, but we have the exception:
Runtime.InteropServices.COMException (0x800401F3): Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))
This error should happen if there aren't the correct information about the Interface in the Windows Registry, but we don't know...
Any idea?
thanks a lot
There's no question you need the COM+ proxy installed on all the client machines, and you want to install it with the proxy installation package. The error you're getting is the result of the missing ProgID entry under the HKEY_CLASSES_ROOT hive in the registry. This registry entry, among others, is provided by the installation package. This isn't all the the proxy installer provides; I found a pretty good overview here.
It sounds like what you are really looking for is to create a custom application manifest for your ClickOnce deployment. This should allow you to bundle the proxy installer as a bootstrap prerequisite into your ClickOnce deployment. However the install will still require administrative permissions; I don't see a way around that (see note below). Here is a link to a tool that works with ClickOnce manifests that was created by Stackoverflow user Greg Jackman. I don't have any experience with this, but based on Greg's post it looks like it may be helpful to you.
One final note: even if you do find a way to run the installation package as a non-elevated user, you don't want to do that. Running non-elevated will change the way the package interacts with the registry. Short story, it will fail silently.
Use group policy to distribute the components?
I need to write a component to retrieve emails from a given Exchange Server account. I don't have a local copy of Exchange and I can't easily get access to the production server. What options do I have? Is there a cut down / free development version of Exchange? Is there an API that I can code against and then just deploy and test in live?
You can download a 120 day evaluation version of Exchange 2010 from http://www.microsoft.com/exchange/en-us/try-it.aspx
Threre is also a link on that page to set up a test against an online version
Without having a staging and/or test environment with another instance of exchange running, you might be out of luck.
I would also approach this from a design stand-point. You likely want to test your logic independently of Exchange (i.e. you don't want to test Exchange and you may want to test code that uses your code that interfaces with Exchange but don't necessarily want to re-test the code that interfaces with Exchange--and take the performance his of a round-trip to/from Exchange). So, I would look at Dependency Inversion and mocking as a means of separating your code from being directly dependant on a existing, available, and operational instance of exchange running.
There is no way you can simulate it (as far as I know via 3rd party apps that is), however you can sign-up for the free Office 365 beta (or any other hosted exchange trials) point your Visual Studio to
http://[whatever pod hosting your mailbox].outlook.com/ews/Exchange.asmx
add it as a WebService reference and get on with your development. Best of luck.