B2b web Service Guidelines V2 rsvz enterprise Architecture
Download 0.95 Mb.
|
- Navigate this page:
- Social Insurance Fund
Certificate RenewalThe validity of an X.509 certificate is always limited in time – both the start date, and the end date. Different steps need to be taken when a certificate approaches its expiration date, depending on whether the certificate represents a Social Insurance Fund or RSVZ.
Social Insurance FundA Social Insurance Fund MUST use the following procedure to renew a certificate: The SIF obtains the serial number and common name (CN) from the certificate that need to be renewed. On Windows, double-clicking a certificate in PEM format (usually with extension .crt or .cer) opens a certificate viewer. On the Details tab, the values of the Serial number and Subject (containing the CN) attributes can be read. For example:  
Alternatively, one can use openssl to obtain this information. For example: openssl x509 -noout -serial –subject -in "b2b.rsvz-inasti.fgov.be.crt" subject=/CN=b2b.rsvz-inasti.fgov.be/C=BE/OU=0208044709/O=RSVZ/INASTI serial=01000000000120611F51AA
Send an e-mail to the CA – in case of Fedict: ca@fedict.be – asking for the renewal of a certificate mentioning the common name and serial number you obtained from step 1. Once the SIF has obtained the new certificate – in case of Fedict this should be within 2 to 3 working days – it MUST be distributed to RSVZ (b2b@rsvz-inasti.fgov.be) as soon as possible. RSVZ adds the new certificate to its trust, and - in case of a client certificate - authentication store. The SIF imports the new certificate into its security store to start using it. RSVZ removes the original certificate from its trust or authentication store. When we put these steps into a timeline, this leads to the following result: 
T is the expiration date of the certificate. The point in time of each event on the timeline is expressed as the number of days before T. So the renewal procedure MUST be started about 30 days before the certificate expires, and the renewed certificate becomes active 15 days before the original certificate expires. RSVZWhen a certificate from RSVZ need to be renewed, the following procedure MUST be executed: RSVZ obtains the serial number and common name (CN) from the certificate that need to be renewed. RSVZ sends an e-mail to ca@fedict.be asking for the renewal of a certificate providing the common name and serial number of the certificate to renew. Once RSVZ has obtained the new certificate it MUST be distributed to all SIFs as soon as possible, and published on the public web site. The SIFs add the new certificate to their trust and/or authentication store. RSVZ imports the new certificate into its security store to start using it. The SIFs remove the original certificate from their trust or authentication store. This leads to the following timeline: 
T is the expiration date of the certificate. The point in time of each event on the timeline is expressed as the number of days before T. Since more parties (multiple SIFs and RSVZ) are involved, the renewal procedure MUST be started about 45 days before the certificate expires, and the renewed certificate becomes active 15 days before the original certificate expires. As the certificates for the individual environments at RSVZ (test, acceptance and production) expire at about the same time, all steps – except step 5 – will be executed in parallel for all environments. Step 5 will first be executed in test, then acceptance and finally in production. This allows SIFs to test the effects of the certificate renewel first in non-critical environments. Note: The latest version of the client and server certificates of RSVZ for each environment is available for download from http://www.rsvz-inasti.fgov.be/schemas/B2B-certificates. 1 The message structure of Web Services is defined by the SOAP protocol. The term Web Service is really an umbrella term, covering lots of standards, of which SOAP is the base standard. 2 The SOAP specification mentions Request-Response and One-Way, and is similar to our concepts. The WSDL specification has 4 message exchange patterns, including Request-Reply and One-Way, but is very abstract, binding dependent, and unclear. In practice the solutions we propose here work very well in soap and wsdl. 3 WS-Attachments are also not a solution for this: standards are still a moving target, as is vendor adoption. 4 The next WSDL standard, version 2.0, solves this problem, but this standard is not yet implemented by software vendors. Moreover there seems to be a lot of scepticism about this standard. 5 Strictly speaking this is outside the scope of the guideline since this is not under our control, but added for completeness. 6 Persistent Store is explained in the previous guideline on Pseudo One Way. 7 Note that the sender may also choose to stop sending messages in case of a System Error. 8 We do not and cannot include services that RSVZ-INASTI does not control, such as web services defined by KSZ. 10 Note that this implies that the flux is also phasing out. 11 Release Candidates are not covered here. Directory: schemas schemas -> Recommended list of diagrams for the Anatomy final examination Skeleton, joints, muscles schemas -> State of Maine-Sample Automobile Lifts and Hoists Schema-Sample Download 0.95 Mb. Share with your friends:
|